Bug#1071470: slic3r-prusa: diff for NMU version 2.7.4+dfsg-1.1
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 +-TKSTEPAttr +-TKSTEPBase ++TKDESTEP ++TKDESTL + TKXCAF + TKXSBase + TKVCAF I trust your judgement, but it's not a straight-forward change and I don't know OpenCascade well enough. Regards, Gregor
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1006540: renpy: Move package to experimental while porting is still in progress
Package: renpy Version: 7.3.5+dfsg-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Please consider moving the Debian Ren'Py package from sid to experimental. It is currently in an unusable state, because the Python 3 porting process is still ongoing. It doesn't make any sense to have it in testing right now, and unstable is probably not ideal either. FWIW, the package currently doesn't install properly: --- snip --- Setting up renpy (7.3.5+dfsg-2) ... File "/usr/share/games/renpy/launcher/game/gui7/code.py", line 283 l = re.sub(ur'_\((\".*?\")\)', replace, l) ^ SyntaxError: invalid syntax File "/usr/share/games/renpy/launcher/game/pefile.py", line 88 IMAGE_ORDINAL_FLAG = 0x8000L ^ SyntaxError: invalid syntax --- snip, similar errors follow --- According to [1], there are preliminary Ren'Py 8 releases with Python 3 support. It would be great to have packages built from the upstream nightlies [2], so people can start testing them in Debian. Thank you! [1] https://github.com/renpy/renpy/issues/2003#issuecomment-1016741906 [2] https://nightly.renpy.org/current-8/index.html -- 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 5.15.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages renpy depends on: ii fonts-dejavu-core 2.37-2 ii fonts-motoya-l-cedar 1.01-5 ii fonts-nanum 20200506-1 ii fonts-roboto-hinted 2:0~20170802-3 ii python-renpy 7.3.5+dfsg-2 ii python3 3.9.8-1 ii python3-pygame-sdl2 7.4.10-1+b1 Versions of packages renpy recommends: ii python-tk2.7.18-1 ii python2 [python-ctypes] 2.7.18-3 ii zenity 3.41.0-2 renpy suggests no packages. -- no debconf information
Bug#1003962: Fails with --buildsystem=cmake if builddirectory contains package version with ~ tilde
> I suspect the error is in /usr/share/dh-python/dhpython/build/plugin_cmake.py:
>
> return ('dh_auto_build --buildsystem=cmake'
> ' --builddirectory="{build_dir}"'
>
> If I replace "{build_dir}" by {build_dir} in that file, the build
> succeeds.
Is that safe?
What if the build_dir contains spaces or shell characters?
Perhaps the command should be single quoted instead, or the resulting
strings should be escaped.
Bug#1001273: gcc-avr,gcc-sh-elf: both ship /usr/lib/libcc1.so*
> Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > /usr/lib/libcc1.so > /usr/lib/libcc1.so.0 > /usr/lib/libcc1.so.0.0.0 To be honest, this sounds like a packaging issue. libcc1.so should not be installed by a specific cross compiler at all, at least not for the host architecture and certainly not into /usr/lib. If the libcc1 versions used by gcc-avr and/or gcc-sh-elf are incompatible with what's provided by libcc1-0, then these two packages should either be linked statically or their own versions be installed into /usr/lib//lib (or something similar) FWIW, this is likely caused by these two cross compilers being based on very old gcc versions. At least gcc-avr should be fixed by upgrading it to something newer than the Atmel/Microchip-patched version. Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989
Bug#980603: [3dprinter-general] Bug#980603: cura: FTBFS: cura/PrinterOutput/Models/MaterialOutputModel.py:6: error: Module 'PyQt5.QtCore' has no attribute 'pyqtProperty'
> Re: Lucas Nussbaum > > > 14/14 Test #1: code-style ...***Failed 61.38 sec > > > cura/PrinterOutput/Models/MaterialOutputModel.py:6: error: Module > > > 'PyQt5.QtCore' has no attribute 'pyqtProperty' > > Fwiw cura still works fine here, so I'd claim this is a test-only > problem which we should probably mute unless there's an easy fix. Could this be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973230 ? > > The following tests FAILED: > > 1 - code-style (Failed) If this is true and the failures are really only code style issues, I would suggest to silence the unit test and be done with it. But it does look a bit more serious from the error messages. I reported it upstream. While we wait, I think it'll be ok to disable the unit test and upload a new version. Here's a patch, feel free to release if you agree: https://salsa.debian.org/3dprinting-team/cura/-/commit/03fde269efaced553a7c4e74846e2554dd2f6bcf (or revert it, if you think we should rather wait for upstream)
Bug#938351: marked as pending in renpy
> https://salsa.debian.org/games-team/renpy/commit/fc29ebfe106238b590a7896450a5d1ad1f94f84e > > > Switch to python3. > > Closes: #938351 > I'm confused. Does that mean upstream has completed the port to Python 3? Last I checked, the bug was still wide open: https://github.com/renpy/renpy/issues/1098
Bug#972808: [3dprinter-general] Bug#972808: cura-engine FTBFS: error: ‘find_if’ is not a member of ‘std’
> A native build of cura-engine on unstable amd64 ends with:
>
> | In file included from /usr/include/gtest/gtest.h:387,
> | from /<>/tests/utils/SparseGridTest.cpp:4:
> | /<>/tests/utils/SparseGridTest.cpp: In member function
> ‘virtual void cura::GetNearbyTest_GetNearby_Test::TestBody()’:
> | /<>/tests/utils/SparseGridTest.cpp:48:38: error: ‘find_if’ is
> not a member of ‘std’; did you mean ‘find’?
> |48 | EXPECT_NE(result.end(), std::find_if(result.begin(),
> result.end(), [](const typename SparsePointGridInclusive::Elem
> ) { return elem.val == point; }))
> | | ^~~
This has been fixed upstream:
https://github.com/Ultimaker/CuraEngine/issues/1318
> This must be a very recent issue as neither crossqa (10 days ago) nor
> reproducible builds (6 days ago) have run into this issue. It's reliably
> reproducible anyhow. I'm unsure what might cause it. Neither gcc-10 nor
> cura-engine were uploaded in that time. It would be a good idea to add
> the missing #include any how.
Not sure, perhaps it was a change in one of the dependent libraries
(such as gtest).
Anyway, the fix should be in the next CuraEngine release (4.8), but we
can adopt the trivial patch from here in the meantime:
https://github.com/Ultimaker/CuraEngine/commit/ae354d80b25d90576f37222b6500f0e7ac45405b
Bug#970111: enigmail: Upgrade to migration version 2.2.x for Thunderbird 78
Thunderbird 78.3.1 is now in unstable, and without Enigmail 2.2, existing users may lose their existing configuration. Please consider uploading the migration wizard (i.e. Enigmail 2.2) as soon as possible.
Bug#961373: slic3r-prusa FTBFS on armhf: cc1plus: out of memory
> cc1plus: out of memory allocating 9048820 bytes after a total of 77602816 > bytes How about increasing the memory on the build machine or preventing a parallel make? 90MB memory usage doesn't sound dramatic to me.
Bug#970111: enigmail: Upgrade to migration version 2.2.x for Thunderbird 78
Tags: patch
Here's a series of patches for packaging the latest version.
0435-Use-upstream-repository-for-watch.patch should be applied first, so
import-orig --uscan will pick up tags from the upstream repo. I don't
think the signature option is working as intended, but I don't know how
to fix it so signatures are imported as well.
Then, after importing the newer upstream releases, the other patches can
be applied.
I haven't tested the resulting xpi yet.
From 028146af85f65766d92af20088b8644630880fd7 Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Sun, 13 Sep 2020 11:45:02 +0200
Subject: [PATCH 435/439] Use upstream repository for watch
---
debian/watch | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/debian/watch b/debian/watch
index 17a6fb86..56be7ccf 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,2 @@
version=4
-opts=pgpsigurlmangle=s/$/.asc/,dversionmangle=s/\+ds1$//,repacksuffix=+ds1 \
- https://www.enigmail.net/download/source.php .*/enigmail-([\d\.]*).tar.gz
+opts="pgpmode=next" https://gitlab.com/enigmail/enigmail/tags?sort=updated_desc archive/enigmail-@ANY_VERSION@/enigmail-enigmail-\d\S*@ARCHIVE_EXT@
--
2.28.0
From 33c721d334fd45853eac174a8e0954b51517ba44 Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Sun, 13 Sep 2020 14:03:20 +0200
Subject: [PATCH 436/439] Fix up dependencies
---
debian/control | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 89632375..2d7a2078 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Uploaders:
Alexander Sack ,
Willi Mann ,
Daniel Kahn Gillmor ,
+ Gregor Riepl
Build-Depends:
debhelper-compat (= 12),
perl,
@@ -23,7 +24,7 @@ Architecture: all
Depends:
gnupg (>= 2.2.8-2~),
gnupg-agent,
- thunderbird (>= 1:68.0) | icedove (>= 1:68.0),
+ thunderbird (>= 1:78.0) | icedove (>= 1:78.0),
${misc:Depends},
Recommends:
pinentry-x11,
@@ -35,12 +36,16 @@ Enhances:
icedove,
thunderbird,
Breaks:
- icedove (<< 1:68.0),
- thunderbird (<< 1:68.0),
+ icedove (<< 1:78.0),
+ thunderbird (<< 1:78.0),
Description: GPG support for Thunderbird and Debian Icedove
OpenPGP extension for Thunderbird. Enigmail allows users to access the
features provided by the popular GnuPG software from within Thunderbird.
.
+ This version of the extension provides a migration assistant for
+ converting Enigmail configurations to the built-in OpenPGP support in
+ Thunderbird 78.
+ .
Enigmail is capable of signing, authenticating, encrypting and decrypting
email. Additionally, it supports both the inline PGP format, as well as the
PGP/MIME format as described in RFC 3156.
--
2.28.0
From 41e46e01ff8c61f2327b0d5eb7a0f6b0fd4d310e Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Sun, 13 Sep 2020 14:09:43 +0200
Subject: [PATCH 437/439] Remove obsolete eslint patch
---
debian/control| 1 +
.../0001-avoid-eslint-during-buildtest.patch | 24 ---
debian/patches/series | 1 -
3 files changed, 1 insertion(+), 25 deletions(-)
delete mode 100644 debian/patches/0001-avoid-eslint-during-buildtest.patch
diff --git a/debian/control b/debian/control
index 2d7a2078..0de2db4f 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Build-Depends:
python3,
unzip,
zip,
+ eslint,
Standards-Version: 4.5.0
Homepage: https://www.enigmail.net/
Vcs-Git: https://salsa.debian.org/debian/enigmail.git -b debian/experimental
diff --git a/debian/patches/0001-avoid-eslint-during-buildtest.patch b/debian/patches/0001-avoid-eslint-during-buildtest.patch
deleted file mode 100644
index 19b77389..
--- a/debian/patches/0001-avoid-eslint-during-buildtest.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-From: Daniel Kahn Gillmor
-Date: Mon, 25 Jan 2016 13:22:44 -0500
-Subject: avoid eslint during buildtest
-
-eslint is not yet in debian (see https://bugs.debian.org/743404).
-once it is packaged, we should remove this patch and allow the full
-testsuite to run on the debian buildd infrastructure.
- Makefile | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/Makefile b/Makefile
-index 308c34a..f74f9e5 100644
a/Makefile
-+++ b/Makefile
-@@ -43,7 +43,7 @@ unit:
- make -C ui/tests
- make -C ipc/tests
-
--test: eslint check unit
-+test: check unit
-
- clean:
- rm -f build/$(XPIFILE) .eslintcache
diff --git a/debian/patches/series b/debian/patches/series
index d5fbba93..ec657037 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,4 +1,3 @@
-0001-avoid-eslint-during-buildtest.patch
0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch
0003-avoid-OpenPGP.js-when-building.patch
0004-copy-enums.armor-from-OpenPGP.js.patch
--
2.28.0
From 9853f70f9d2d8a46049929d1c9e4e15bace2b5ea Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Sun, 13 Sep 2020 14:30:06 +0200
Subject: [PATCH 438/439] Drop obso
Bug#970111: enigmail: Upgrade to migration version 2.2.x for Thunderbird 78
Package: enigmail Version: 2:2.1.6+ds1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Please consider uploading the latest 2.2 version of Enigmail to support the ongoing Thunderbird upgrade to version 78. This version includes a migration wizard for existing Enigmail configurations, which will become obsolete due to the integration of PGP support in Thunderbird. Since the Thunderbird 78 package in Debian contains a Breaks: on Enigmail << 2.2, it will cause Enigmail to be removed when upgrading Thunderbird. This will lead to users missing out on the conversion wizard. d/watch refers to the project homepage and not the Gitlab page, so it currently doesn't detect these new versions. The code for Enigmail 2.2 can be found here: https://gitlab.com/enigmail/enigmail/-/tags It's possible that Enigmail 2.2 no longer contains functionality for Thunderbird << 78, so careful testing of the package is needed. Thunderbird 78 is currently only available in experimental, so an upload to experimental first would be a good idea. Thank you. -- System Information: Debian Release: bullseye/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 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages enigmail depends on: ii gnupg2.2.20-1 ii gpg-agent [gnupg-agent] 2.2.20-1 ii thunderbird 1:68.12.0-1 Versions of packages enigmail recommends: ii pinentry-qt [pinentry-x11] 1.1.0-4 enigmail suggests no packages. -- no debconf information
Bug#966898: binutils-avr: FTBFS: elf.c:706:35: error: overflow in conversion from ‘unsigned int’ to ‘int’ changes value from ‘num_group = 4294967295’ to ‘-1’ [-Werror=overflow]
> > elf.c: In function ‘setup_group’: > > elf.c:706:35: error: overflow in conversion from ‘unsigned int’ to ‘int’ > > changes value from ‘num_group = 4294967295’ to ‘-1’ [-Werror=overflow] > > 706 | elf_tdata (abfd)->num_group = num_group = -1; Upstream bug is here: https://sourceware.org/bugzilla/show_bug.cgi?id=25717 This was fixed upstream by: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=cda7e5603f6efd7c3716e45cc6ea11b70dd8daae Looks like it's caused by GCC 10 being more picky about signedness. > > In file included from elf.c:45: > > elf.c: In function ‘elfcore_write_linux_prpsinfo32’: > > elf-linux-psinfo.h:73:7: warning: ‘strncpy’ output may be truncated copying > > 16 bytes from a string of length 16 [-Wstringop-truncation] This and the rest of the errors are false positives occurring from GCC 8 onwards. They have been silenced upstream: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a6312e8c015d4a98020038f3b6e144db230f3ca https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b9f26d2e29bb56a0404216c5612d6d7fee54a769 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d99b4b92c8ed0f7ef98f370bbf65a360ed66ad7b https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=602f16570454a1597c2af28af66852133432d1f2 (there may be other patches as well) Related bug reports: https://sourceware.org/bugzilla/show_bug.cgi?id=23146 (can't find any that describe the original problem) Also, please note that elf-linux-psinfo.h was renamed to elf-linux-core.h upstream: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=de64ce13a78669f094d6909fce51d210e2f9d2c0 Perhaps it's time to replace the outdated Atmel versions of avr-gcc avr-binutils and avr-libc in favour of the upstream versions?
Bug#967915: Depends on geda-gaf
> geda-gaf is scheduled for removal (#965098) and gspiceui depends on it. > > Quoting Bdale in the RM bug above: > It looks like the last gspiceui upstream release was in late 2018, and > the only reason it depends on geda-gaf is that it wants to use gnetlist > to import schematic data from gschem. Updating that to use > lepton-netlist to import schematic data from lepton-schematic should be > a pretty simple search and replace operation if keeping gspiceui seems > worthwhile (I don't know, I've never used it). I'd prefer that gspiceui be kept. I don't care much for gEDA and if the dependency isn't strictly necessary or can be replaced with lepton-netlist, I'm all for it. As a matter of fact, it looks like there is already code in place to search for lepton-netlist in addition to gnetlist: https://salsa.debian.org/science-team/gspiceui/-/blob/master/src/TypeDefs.hpp#L112-130 It should be enough to replace the dependencies on geda-gschem and geda-gnetlist with lepton-eda.
Bug#956543: freecad: FTBFS with new opencascade 7.4 (library transition)
> Status update why this package has not yet been updated: > If the freecad is rebuilt against pyside2, it will run > into 945376 at runtime, namely when opening the PartDesign workbench. > As this is a major feature in freecad and the current version in > sid works its better to wait until pyside2 has been fixed. 945376 got a fix in experimental now. freecad is currently not co-installable with kicad, because the latter was already transitioned to opencascade 7.4. Would you consider a fixed freecad upload to experimental as well? That way, the pyside2 bugfix could be tested with an updated freecad build. > For that, several QT dependencies pyside have to be updted: > - qtdatavis3d-everywhere-src > - qtscxml-everywhere-src > - qtspeech-opensource-src > - qtxmlpatterns-opensource-src > > Bugs have been filed against those package, they should block this bug. I didn't see any bug reports on these packages, is there still work to be done on them?
Bug#946532: uranium: build depends on cruft package
> Hello, your package build depends on a cruft package, I'm uploading a fix in > deferred/5 > > patch is here: (I'll close the bug before uploading) > - pylint3, python3-pytest, > + pylint, python3-pytest, > python3-pyqt5, Thanks a lot for this! I tested locally and pushed 3.3.0-2 that includes this patch. Unfortunately, but I can't upload as I'm not a DD. Can you or someone from the 3-D printing team push the fixed version from Salsa for me? -> https://salsa.debian.org/3dprinting-team/uranium/-/tags/debian%2F3.3.0-2 Also, it doesn't look like deferred/5 worked as intended: https://ftp-master.debian.org/deferred.html says the upload was only queued for about 2 days, not 5...
Bug#936046: python3-pyqt5: does not depends on matching qtbase-abi
Looks like the dependency chain is fixed, python3-pyqt5 is installable again. Thanks.
Bug#936046: python3-pyqt5: does not depends on matching qtbase-abi
> A transition is in progress right now. Some packages will be uninstallable > until the release team rebuilds them. Hopefully that will happen later this > week. > > Please follow the transition bug (https://bugs.debian.org/941093) to track > its state. Thanks for the info! signature.asc Description: OpenPGP digital signature
Bug#927991: Fix for FTBFS
Dear maintainer, With the latest upload of MariaDB 10.3, --libmysqld-libs is now supported by mysql_config/mariadb_config: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928230#46 Can you please trigger a rebuild of amarok once mariadb-10.3_1:10.3.15-1 has hit unstable? Please also consider unblocking the package so it can still go back into buster, if possible. Thanks!
Bug#927991: Your mail
> MariaDB still supports it, and there's a separate package called libmariadbd > containing it. However, mariadb_config doesn't support getting the > corresponding build flags. A little update on that one. The manpage for mysql_config clearly states that --libmysqld-libs is a supported option: https://github.com/MariaDB/server/blob/10.3/man/mysql_config.1 (yes, Debian has the very same man page) However, the /usr/bin/mysql_config executable in libmariadb-dev-compat differs from the upstream mysql_config.sh script: https://github.com/MariaDB/server/blob/10.3/scripts/mysql_config.sh Looking further, the mysql_config binary is actually a symlink to mariadb_config: https://github.com/MariaDB/server/blob/10.3/debian/libmariadb-dev-compat.links And mariadb_config does not support the requested option: https://github.com/MariaDB/mariadb-connector-c/blob/10.3/mariadb_config/mariadb_config.c.in I think it would make sense to report this upstream and replace the symlink with the shell script.
Bug#927991: (no subject)
FYI, this flag is used to request build arguments for linking against the embedded MySQL server library. That library was removed in MySQL 8.0: https://mysqlserverteam.com/mysql-8-0-retiring-support-for-libmysqld/ MariaDB still supports it, and there's a separate package called libmariadbd containing it. However, mariadb_config doesn't support getting the corresponding build flags. If Amarok can work without the embedded MySQL server, I think a quick fix would be to remove the check for libmysqldbd/libmariadbd. Otherwise, the cmake find script needs to be patched.
Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth
> Looks OK to me. Ok... So it turns out I made a stupid versioning mistake when preparing a fixed version of libpolyclipping. After fixing that and reinstalling the correct pkg-config file, I can build cura-engine again. I'll ask Petter to upload libpolyclipping-6.4.2-6 ASAP.
Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth
>> That, or the fix wasn't enough.
>
> Works for me.
Odd.
> What failure are you getting, and what is the contents
> of /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc ?
I'm getting the same pthread detection error as reported in the bug.
Contents:
$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
sharedlibdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/polyclipping
Name: polyclipping
Description: polygon clipping library
Version:
Requires:
Libs: -L${libdir} -L${sharedlibdir} -lpolyclipping
Cflags: -I${includedir}
Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth
>> I will look into the issue. >> If you have any idea why it might be occurring, please share. > > The actual error is in #917057, which was already correctly marked as > affecting src:cura-engine. I'm positive that the problem is more complex than that, because I already committed and tested the fix for #917057 and I still get an error. That, or the fix wasn't enough.
Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth
Thanks for the bug report. Building the package used to work fine, so I'm suspecting the pthread detection scripts have started failing with glibc 2.28, which was updated recently. I will look into the issue. If you have any idea why it might be occurring, please share.
Bug#917057: [3dprinter-general] Bug#917057: libpolyclipping-dev: pjg-config file contains bogus includedir
> Thanks for spotting. That was not the cause however. The upstream > polycipping.pc.in relies on very weired assignments of standard cmake > variables, those assignments were removed in > debian/patches/1000-fix-multiarch-paths.patch, which was added in the > same upload that fixed #915267. > > The attached patch adapts polycipping.pc.in to cope with > 1000-fix-multiarch-paths.patch. Thanks, Helmut. I totally missed this. Since upstream[1] is practically dead, we're pretty much on our own here... I'll make sure the patch is included with the next upload. [1] https://sourceforge.net/p/polyclipping/
Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures
> I suspect that many optional symbols on the symbols file of this package > could be squashed with a regex, but alas I can't help with that now > since I'll be soon leaving for a 2-weeks travel and I don't think I > would ever find the time to also look at this. Anyway, look at the gdcm > repo for an idea of what I'm talking about. Not sure if a regex is appropriate here, since some of the symbols come and go, depending on the compiler, dependencies and architecture. But I'll take look, thanks for the hint. > Anyway, the problem that dpkg-gensymbols is complaining about, it's > because you missed a quote sign in > a4f32173da0f7ab5c173d89fd556f0af242d2deb (didn't you notice this while > test building before asking for sponsorship?). Ouch, thanks for pointing that out. I totally didn't see this. Thought there was something wrong with the Debian-tagged version I added. > After that my local build failed because I locally export > DPKG_GENSYMBOLS_CHECK_LEVEL=4 and it seems this new symbol is new: > > _ZNSt10_HashtableIPKN6google8protobuf10DescriptorESt4pairIKS4_jESaIS7_ENSt8__detail10_Select1stESt8equal_toIS4_ESt4hashIS4_ENS9_18_Mod_range_hashingENS9_20_Default_ranged_hashENS9_20_Prime_rehash_policyENS9_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEmmPNS9_10_Hash_nodeIS7_Lb0EEEm@Base>> Anyway, that's yet another std:: function leaked from who knows where, > so nvm that… I'll raise the issue on the developer's issue tracker and see if I can send them a patch. Far too much time has been wasted on this already.
Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures
I'm inclined to drop the symbols file altogether, as it really doesn't add any value. The correct solution would be to use -fvisibility=hidden [1] and properly tag symbols for the public API of libArcus and libSavitar. For what it's worth, libArcus.so.3 is currently only used by python3-arcus and CuraEngine anyway, and it's unlikely that this will change. Another option would be to put all the internal Cura libraries into a private lib folder, but I suspect this is risky and even more work than adding symbol visibility. [1] http://gcc.gnu.org/wiki/Visibility
Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures
> Hi, I saw that you asked for sponsorship on the ML¹ but then pere failed > to build the package². Could you please have a look soon? Sorry, got held up by the mess that is symbols files for C++ libraries that don't properly hide internal symbols. I'll try to get this sorted out ASAP. Do you know who I could talk to for help with C++ symbols file issues?
Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures
Ok, it looks like I misunderstood how binNMUs work, so I'll simply prepare a release then. [1] [1] https://wiki.debian.org/binNMU
Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures
> for the Python 3.7 default transition, libarcus was binNMUed against > Python 3.7, but FTBFS on at least amd64, arm64, i386, mips, ppc64el > and s390x: > > https://buildd.debian.org/status/package.php?p=libarcus=unstable > > So far it only build fine only on these release architectures" armel, > armhf, mipsel64. Thanks for reporting. I'd like to fix this ASAP, but I just noticed that the NMU was never imported back into the repository. I'll add those imported library symbols and prepare a release as soon as I've tracked the changes down.
Bug#907157: [3dprinter-general] Bug#907157: cura-engine: diff for NMU version 1:3.3.0-2.1
> I've prepared an NMU for cura-engine (versioned as 1:3.3.0-2.1) and > uploaded it to DELAYED/15. Please feel free to tell me if I should > cancel it. Thanks for uploading. As the patch is from upstream, I assume it won't be required for newer CuraEngine versions? I had hoped that I could continue working on Cura, as there are a bunch of open questions (like how to package stb). But I simply didn't have time to do so. But it's better to provide a quick fix than to wait for an update indefinitely...
Bug#903825: Package maintenance
I'd be ready to adopt the package, if this is what's missing to get it back into Debian. A DD involved with the sparc64 port offered to sponsor it as well. The driver hasn't been updated upstream since 2013, but it is still compatible with recent X.org builds. I just tested it on a Sun Ultra 10 this morning. What else is needed to get the package back into Debian? Do I need to join the xorg task force?
Bug#903825: xserver-xorg-video-sunffb: sparc64 architecture is disabled
Package: xserver-xorg-video-sunffb Version: 1:1.2.2-1 Severity: grave Justification: renders package unusable Dear Maintainer, Debian has dropped support for the sparc (32-bit) architecture some time ago, but a dedicated debian-ports team has started working on a sparc64 port. Since this port is already very mature, it would make sense to bring back some old packages that were only supported on sparc. The Xorg sunffb driver is one of them. Please add the "sparc64" to the list of build Architectures: in d/control, so this package returns to the repositories. I have verified that building on sparc64 works, but I haven't tested the resulting driver yet. Thank you! -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable'), (50, 'experimental') Architecture: sparc64 Kernel: Linux 4.16.0-2-sparc64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#892849: [3dprinter-general] Bug#892849: Bug#892849: cura: Exception while launching cura
> ii libarcus3 3.1.0-1 amd64 message queue for Cura based on p > ii python3-arcus 3.1.0-1 amd64 message queue for Cura based on p > ii python3-sip 4.19.8+dfsg- amd64 Python 3/C++ bindings generator r Thank you. Unfortunately, I cannot reproduce the problem on my machine, even with these exact versions from sid installed. But I'm using a sid/stretch mix, not pure sid, so it may be related to that. On the other hand, I will submit Cura 3.2.1 soon, so perhaps a new build will help. I'll keep the bug open until then. If it still happens with 3.2.1, we'll need to debug this further.
Bug#892849: [3dprinter-general] Bug#892849: cura: Exception while launching cura
> the sip module implements API v12.0 to v12.2 but the Arcus module requires > API v12.3 Can you give me the output of dpkg-query -l libarcus3 python3-arcus python3-sip ? signature.asc Description: OpenPGP digital signature
Bug#888297: p7zip: Multiple Memory Corruptions via RAR and ZIP
> Since they are in two different source packages let's actually create > two bugs. Ah, I hadn't noticed that. Thanks for splitting and retagging.
Bug#888297: p7zip: Multiple Memory Corruptions via RAR and ZIP
Package: p7zip Version: 16.02+dfsg-4 Severity: grave Tags: upstream newcomer security Justification: user security hole Dear Maintainer, p7zip, p7zip-full and the non-free component p7zip-rar are affected by two vulnerabilities: https://landave.io/2018/01/7-zip-multiple-memory-corruptions-via-rar-and- zip/?hn In particular, the RAR3 and LZW algorithm implementations are susceptible to memory corruption and may compromise a system through specially crafted archives. These issues have already been fixed upstream, and a new version of p7zip (18.0) is available. Please update all p7zip* packages to their latest versions as soon as possible. Thank you. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (900, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages p7zip depends on: ii libc6 2.26-2 ii libgcc1 1:7.2.0-19 ii libstdc++6 7.2.0-19 p7zip recommends no packages. Versions of packages p7zip suggests: ii p7zip-full 16.02+dfsg-4 -- no debconf information
Bug#881483: libsavitar: Incomplete debian/copyright?
Good morning. > I just ACCEPTed libsavitar from NEW but noticed it was missing > attribution in debian/copyright for at least Kristen Wegner > for pugixml. So, I rechecked that part. The reason why there was no attribution to Kristen Wegner was because of the wording "Based on". I assumed this part was rewritten by the pugixml author and he was just giving credit. Apparently I was wrong - and the Debian libpugixml-dev package that we're compiling against says otherwise too. > (This is not exhaustive so please check over the entire package > carefully and address these on your next upload.) All right. I rechecked all files manually and with license-reconcile, but there doesn't seem to be anything else.
Bug#881483: libsavitar: Incomplete debian/copyright?
Hi, > I just ACCEPTed libsavitar from NEW but noticed it was missing > attribution in debian/copyright for at least Kristen Wegner > for pugixml. > > (This is not exhaustive so please check over the entire package > carefully and address these on your next upload.) Thanks. I will look into this ASAP. Regards, Greg
Bug#849832: No longer affects FF55/56
According to https://bugzilla.mozilla.org/show_bug.cgi?id=1357323 , this bug should no longer affect Firefox 55 and 56, as the gonk code was removed from the tree. Please confirm.
Bug#856951: Quilt patch
In case upgrading the package is too much work, here's a quilt patch you can
apply on top of the Debian git repository.
>From d2fdbd805683183d92586160445207963712d6af Mon Sep 17 00:00:00 2001
From: Gregor Riepl <onit...@gmail.com>
Date: Mon, 26 Jun 2017 09:00:24 +0200
Subject: [PATCH 1/2] Added libcontainer cgroup2 bugfix
---
debian/patches/libcontainer-cgroup2-bugfix.patch | 83
debian/patches/series| 1 +
2 files changed, 84 insertions(+)
create mode 100644 debian/patches/libcontainer-cgroup2-bugfix.patch
diff --git a/debian/patches/libcontainer-cgroup2-bugfix.patch b/debian/patches/libcontainer-cgroup2-bugfix.patch
new file mode 100644
index ..2b4767eb
--- /dev/null
+++ b/debian/patches/libcontainer-cgroup2-bugfix.patch
@@ -0,0 +1,83 @@
+diff --git a/libcontainer/cgroups/utils.go b/libcontainer/cgroups/utils.go
+index 9f9105a5..5804d685 100644
+--- a/libcontainer/cgroups/utils.go
b/libcontainer/cgroups/utils.go
+@@ -127,7 +127,7 @@ func getCgroupMountsHelper(ss map[string]bool, mi io.Reader, all bool) ([]Mount,
+ if sepIdx == -1 {
+ return nil, fmt.Errorf("invalid mountinfo format")
+ }
+- if txt[sepIdx+3:sepIdx+9] != "cgroup" {
++ if txt[sepIdx+3:sepIdx+10] == "cgroup2" || txt[sepIdx+3:sepIdx+9] != "cgroup" {
+ continue
+ }
+ fields := strings.Split(txt, " ")
+diff --git a/libcontainer/cgroups/utils_test.go b/libcontainer/cgroups/utils_test.go
+index eb6c8ce9..d3aa8ef4 100644
+--- a/libcontainer/cgroups/utils_test.go
b/libcontainer/cgroups/utils_test.go
+@@ -93,6 +93,34 @@ const systemdMountinfo = `115 83 0:32 / / rw,relatime - aufs none rw,si=c0bd3d3,
+ 136 117 0:12 /1 /dev/console rw,nosuid,noexec,relatime - devpts none rw,gid=5,mode=620,ptmxmode=000
+ 84 115 0:40 / /tmp rw,relatime - tmpfs none rw`
+
++const cgroup2Mountinfo = `18 64 0:18 / /sys rw,nosuid,nodev,noexec,relatime shared:6 - sysfs sysfs rw,seclabel
++19 64 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:5 - proc proc rw
++20 64 0:6 / /dev rw,nosuid shared:2 - devtmpfs devtmpfs rw,seclabel,size=8171204k,nr_inodes=2042801,mode=755
++21 18 0:19 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:7 - securityfs securityfs rw
++22 20 0:20 / /dev/shm rw,nosuid,nodev shared:3 - tmpfs tmpfs rw,seclabel
++23 20 0:21 / /dev/pts rw,nosuid,noexec,relatime shared:4 - devpts devpts rw,seclabel,gid=5,mode=620,ptmxmode=000
++24 64 0:22 / /run rw,nosuid,nodev shared:24 - tmpfs tmpfs rw,seclabel,mode=755
++25 18 0:23 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:8 - tmpfs tmpfs ro,seclabel,mode=755
++26 25 0:24 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:9 - cgroup2 cgroup rw
++27 18 0:25 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:20 - pstore pstore rw,seclabel
++28 18 0:26 / /sys/firmware/efi/efivars rw,nosuid,nodev,noexec,relatime shared:21 - efivarfs efivarfs rw
++29 25 0:27 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:10 - cgroup cgroup rw,cpu,cpuacct
++30 25 0:28 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:11 - cgroup cgroup rw,memory
++31 25 0:29 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:12 - cgroup cgroup rw,net_cls,net_prio
++32 25 0:30 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,blkio
++33 25 0:31 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup rw,perf_event
++34 25 0:32 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,hugetlb
++35 25 0:33 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,freezer
++36 25 0:34 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,cpuset
++37 25 0:35 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,devices
++38 25 0:36 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,pids
++61 18 0:37 / /sys/kernel/config rw,relatime shared:22 - configfs configfs rw
++64 0 253:0 / / rw,relatime shared:1 - ext4 /dev/mapper/fedora_dhcp--16--129-root rw,seclabel,data=ordered
++39 18 0:17 / /sys/fs/selinux rw,relatime shared:23 - selinuxfs selinuxfs rw
++40 20 0:16 / /dev/mqueue rw,relatime shared:25 - mqueue mqueue rw,seclabel
++41 20 0:39 / /dev/hugepages rw,relatime shared:26 - hugetlbfs hugetlbfs rw,seclabel
++`
++
+ func TestGetCgroupMounts(t *testing.T) {
+ type testData struct {
+ mountInfo string
+@@ -245,3 +273,30 @@ func TestParseCgroupString(t *testing.T) {
+ }
+
+ }
++
++func TestIgnoreCgroup2Mount(t *testing.T) {
++ subsystems := map[string]bool{
++ "cpuset": true,
++ "cpu": true,
++ "cpuacct": true,
++ "memory": true,
++ "devices": true,
++ "freezer": true,
++ "net_cls":
Bug#856951: Bug fixes in 1.0.0-rc3
The upstream patch is contained in 1.0.0-rc3. Please update the package as soon as possible. Thank you!
Bug#840243: calligra-gemini does not launch due to missing QtQuick components
Package: calligra-gemini Version: 1:2.9.11+dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, calligra-gemini will not launch due to the following error: "The Calligra Qt Quick components were not found. This means your installation is broken." On the console, the following error message is printed: file:///usr/share/kde4/apps/calligragemini/calligragemini.qml:22:1: module "org.calligra.CalligraComponents" is not installed import org.calligra.CalligraComponents 0.1 as Calligra It does not matter if calligra-gemini is installed separately or as part of the whole calligra suite. Please make sure these componentes are part of calligra-libs or whichever package they belong. Thank you! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages calligra-gemini depends on: ii calligra-gemini-data 1:2.9.11+dfsg-2 ii calligra-libs 1:2.9.11+dfsg-2 ii calligrastage 1:2.9.11+dfsg-2 ii calligrawords 1:2.9.11+dfsg-2 ii kde-runtime 4:16.08.0-1 ii libc6 2.24-3 ii libkdecore5 4:4.14.23-1 ii libkdeui5 4:4.14.23-1 ii libqt4-declarative4:4.8.7+dfsg-9 ii libqt4-network4:4.8.7+dfsg-9 ii libqt4-opengl 4:4.8.7+dfsg-9 ii libqt4-svg4:4.8.7+dfsg-9 ii libqtcore44:4.8.7+dfsg-9 ii libqtgui4 4:4.8.7+dfsg-9 ii libstdc++66.1.1-11 calligra-gemini recommends no packages. calligra-gemini suggests no packages. -- no debconf information
Bug#803284: plasmashell: Crash in xcb_send_request/xcb_intern_atom
Package: plasma-workspace Version: 4:5.4.2-1 Severity: grave File: /usr/bin/plasmashell Justification: renders package unusable Dear Maintainer, After the latest KDE version bump (4:15.08.2-1), some critical KDE components, including plasmashell, segfault on startup, making KDE almost completely unusable. The crash happens after calling xcb_intern_atom, and in some cases (konsole) after calling XInternAtoms. A bug report against kate was filed by someone else as #803212. A crash log (with some debug info) is attached. At the same time as the KDE upgrade, I received some new xorg packages. It is possible that this is not a bug in KDE at all. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel, armhf Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages plasma-workspace depends on: ii dbus-x111.10.0-3 ii frameworkintegration5.15.0-1 ii gdb 7.10-1 ii kactivities 5.15.0-1 ii kde-cli-tools 4:5.4.2-1 ii kded5 5.15.0-1 ii kinit 5.15.0-1 ii kio 5.15.0-1 ii libc6 2.19-22 ii libcln6 1.3.4-1 ii libdbusmenu-qt5-2 0.9.3+15.10.20150604-1 ii libgcc1 1:5.2.1-22 ii libgps213.11-3 ii libice6 2:1.0.9-1+b1 ii libkf5activities5 5.15.0-1 ii libkf5auth5 5.15.0-1 ii libkf5baloo55.15.0+-1 ii libkf5bookmarks55.15.0-1 ii libkf5completion5 5.15.0-1 ii libkf5configcore5 5.15.0-1 ii libkf5configgui55.15.0-1 ii libkf5configwidgets55.15.0-1 ii libkf5coreaddons5 5.15.0-1 ii libkf5crash55.15.0-1 ii libkf5dbusaddons5 5.15.0-1 ii libkf5declarative5 5.15.0-1 ii libkf5globalaccel-bin 5.15.0-1 ii libkf5globalaccel5 5.15.0-1 ii libkf5guiaddons55.15.0-1 ii libkf5i18n5 5.15.0-1 ii libkf5iconthemes5 5.15.0-1 ii libkf5idletime5 5.15.0-1 ii libkf5itemviews55.15.0-1 ii libkf5jobwidgets5 5.15.0-1 ii libkf5js5 5.15.0-1 ii libkf5jsembed5 5.15.0-1 ii libkf5kdelibs4support5 5.15.0-1 ii libkf5kiocore5 5.15.0-1 ii libkf5kiofilewidgets5 5.15.0-1 ii libkf5kiowidgets5 5.15.0-1 ii libkf5networkmanagerqt6 5.15.0-1 ii libkf5newstuff5 5.15.0-1 ii libkf5notifications55.15.0-1 ii libkf5notifyconfig5 5.15.0-1 ii libkf5package5 5.15.0-1 ii libkf5plasma5 5.15.0-1 ii libkf5plasmaquick5 5.15.0-1 ii libkf5quickaddons5 5.15.0-1 ii libkf5runner5 5.15.0-1 ii libkf5screen6 4:5.4.2-1 ii libkf5service-bin 5.15.0+-1 ii libkf5service5 5.15.0+-1 ii libkf5solid55.15.0-1 ii libkf5su5 5.15.0-1 ii libkf5texteditor5 5.15.0-1 ii libkf5textwidgets5 5.15.0-1 ii libkf5wallet-bin5.15.0-1 ii libkf5wallet5 5.15.0-1 ii libkf5waylandclient54:5.4.2-1 ii libkf5waylandserver54:5.4.2-1 ii libkf5webkit5 5.15.0-1 ii libkf5widgetsaddons55.15.0-1 ii libkf5windowsystem5 5.15.0-1 ii libkf5xmlgui5 5.15.0-1 ii libkf5xmlrpcclient5 5.15.0-1 ii libksgrd7 4:5.4.2-1 ii libkworkspace5-54:5.4.2-1 ii libpam0g1.1.8-3.1 ii libphonon4qt5-4 4:4.8.3-2 ii libplasma-geolocation-interface54:5.4.2-1 ii libprocesscore7 4:5.4.2-1 ii libprocessui7 4:5.4.2-1 ii libqalculate5v5 0.9.7-9.1 ii libqt5core5a5.4.2+dfsg-9 ii libqt5dbus5 5.4.2+dfsg-9 ii libqt5gui5 5.4.2+dfsg-9 ii libqt5network5 5.4.2+dfsg-9 ii libqt5qml5
Bug#803212: qt5x11extras at fault
It looks like downgrading qt5x11extras as described in #802811 fixed the crash for all affected KDE applications in my case. If Kyanos confirms, I think this bug can be closed.
Bug#803212: KDE affected in general, not just kate
I see the same crash since my last package upgrade (today). And it affects not just kate, but _all_ of KDE 5: plasmashell, sddm, konsole, you name it. The crashes produce different backtraces sometimes, but in general, it happens after xcb_intern_atom or XInternAtoms. konsole still uses KDE framework 4 AFAIK, so it calls out to libx11, not libxcb. Could this be a bug in Xorg?
Bug#743883: [Pkg-openssl-devel] Bug#743883: Bug#743883: CVE-2014-0160 heartbeat read overrun (heartbleed)
On 08/04/14 18:32, Kurt Roeckx wrote: jessie is still vulnerable at 1.0.1f-1. jessie has 1.0.1g-1 already, which should fix it. Thank you, it just took a little longer for the package to hit my mirror. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732375: renpy: Ren'Py fails to build due to freetype2 detection error
Package: renpy
Version: 6.15.7-1
Severity: serious
Tags: upstream patch
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
I recently submitted a tiny patch to fix a libavresample problem (#732333).
While testing the changes, I discovered that a build script bug was preventing
the package from being built properly. Upstream already released a fix for
that, but it's not included in any Ren'Py release yet. I propose adding it to
debian/patches so the package builds correctly on testing/unstable and the next
stable.
It will still be required if packages are made for Ren'Py 6.16.*. After 6.17,
it should not be necessary any more.
The upstream patch can also be found on github:
https://github.com/renpy/renpy/commit/608a55b
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages renpy depends on:
ii python 2.7.5-5
ii python-pygame1.9.1release+dfsg-8
ii python-renpy 6.15.7-1
ii python-support 1.0.15
ii ttf-dejavu-core 2.33+svn2514-3
Versions of packages renpy recommends:
ii python [python-ctypes] 2.7.5-5
renpy suggests no packages.
diff --git a/module/setup.py b/module/setup.py
index 12f5eac..9d92184 100755
--- a/module/setup.py
+++ b/module/setup.py
@@ -25,7 +25,7 @@ include(zlib.h)
include(png.h)
include(SDL.h, directory=SDL)
include(ft2build.h)
-include(freetype/freetype.h, directory=freetype2)
+include(freetype/freetype.h, directory=freetype2, optional=True) or include(freetype.h, directory=freetype2)
include(libavutil/avstring.h)
include(libavformat/avformat.h)
include(libavcodec/avcodec.h)
diff --git a/module/ttgsubtable.h b/module/ttgsubtable.h
index 6a49a95..fcbefb8 100644
--- a/module/ttgsubtable.h
+++ b/module/ttgsubtable.h
@@ -3,7 +3,7 @@
#include stdint.h
#include ft2build.h
-#include freetype/ftotval.h
+#include FT_OPENTYPE_VALIDATE_H
typedef struct
{
@@ -101,7 +101,7 @@ typedef struct
typedef struct
{
int LookupCount;
-TLookup *Lookup;
+TLookup *Lookup;
} TLookupList;
typedef struct
