If llvm-15 is supported since 11.1.0, can you consider doing at least this step?
llvm-15 is still in testing while llvm-14 no.
This will hopefully restore openvdb (and blender) in testing (until
llvm-15 also get out).
According to Sylvestre's statement and upstream's comments on their lack of
re
In this particular case, there was nothing to do on your side, that's why
Adrian reassigned
the bug, meaning "not really an issue for you".
The people who have routine in finding quickly whether this is true,
and who might already know what the problem is, are the people who
are having an overv
The following packages have unmet dependencies:
sbuild-build-depends-main-dummy : Depends: python3-skimage but it is not
installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed
Broken build dependencies are often FTBFS in a buil
Cura crashes upon startup.
The problem already got reported on community for cura 5.3 but is also present
in cura 5.0.0-3 :
https://community.ultimaker.com/topic/44538-cura-53-crashs-at-startup-linux/
This problem also got reported for RedHat :
https://bugzilla.redhat.com/show_bug.cgi?id=2252195
Hi,
That doesn't look like a related bug to me, and I didn't encounter it when I
prepared and tested the patch.
Maybe some other dependency changed in the meantime?
Anyway, this should be an easy fix, just add a #include near the top
of the failing unit test source.
I'll have a go, but it cou
Confirmation: The upstream PR fixes the compilation issue, after removing the
duplicate lines.
I combined it into a single patch and pushed it to the repo.
@hyperair: Feel free to release a new Debian version when you can.
Thanks!
This issue was fixed upstream a long time ago:
https://github.com/slic3r/Slic3r/pull/4974
Fedora had the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=2259590
They added a quick&dirty fix to their build files:
https://src.fedoraproject.org/rpms/slic3r/pull-request/12#request_diff
I'
Here's a new patch that should resolve the actual root of the problem[1].
Thanks to PyTom for the hint about the loader.
[1] https://docs.python.org/3/library/sys.html#sys.meta_pathcommit 2901314d05cf0ec29e35b3f8d7199927eaf8001e
Author: Gregor Riepl
Date: Fri Aug 9 00:36:08 2024
Here's a patch that (hopefully) fixes the deprecated APIs that were removed in
FFmpeg 7.--- a/module/ffmedia.c
+++ b/module/ffmedia.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
@@ -71,7 +72,11 @@
}
+#if (LIBAVFORMAT_VERSION_MAJOR < 61)
static int rwo
Here's a quick patch that will at least make renpy work again for me.
I haven't done an exhaustive search for other relative .rpy->.py imports, only
fixed those that produce errors.
--- a/launcher/game/distribute.rpy
+++ b/launcher/game/distribute.rpy
@@ -35,7 +35,7 @@
import store.updater a
File "launcher/game/gui7.rpy", line 31, in
import gui7
ModuleNotFoundError: No module named 'gui7'
I'm getting the same error.
The files seem to be installed, but I'm not sure if the location is correct:
$ dpkg -L renpy | grep gui7
/usr/share/games/renpy/launcher/game/gui7
/usr/share/
Hi, and thanks for the report.
[... snipped ...]
2: if not self._mock_unsafe and (not self._mock_methods or name not in
self._mock_methods):
2: if name.startswith(('assert', 'assret', 'asert', 'aseert',
'assrt')) or name in _ATTRIB_DENY_LIST:
2: > raise Attrib
I think I've tracked down the issue.
UM/Qt/qml/UM/SimpleButton.qml references a UI element called "ColorImage".
This class exists in Qt, but it's private and was probably changed/removed in
Qt6.
However, there's also a ColorImage class in Uranium (Cura's UI toolkit), and I
suspect they actuall
Some messages that may be relevant:
2024-06-25 09:12:27,979 - ERROR - [MainThread] UM.PluginRegistry._findPlugin
[730]: Exception: Import error loading module TrimeshReader
2024-06-25 09:12:27,980 - ERROR - [MainThread] UM.PluginRegistry._findPlugin
[730]: Traceback (most recent call last):
20
that leads here: https://github.com/aws/aws-cli/issues/7905
"cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'"
https://github.com/boto/botocore/pull/2924/files
It's not mentioned in the changelog, but this commit was already included in
1.29.123:
https://github.com/boto/botocore/c
Hi Tobias,
I've prepared an NMU for slic3r-prusa (versioned as 2.7.4+dfsg-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Thank you, but could you explain where this patch is coming from?
+ set(OCCT_LIBS
+-TKXDESTEP
+-TKSTEP
+-TKSTEP209
If a fix for this can't be released on time, I'm requesting an exception for
llvm-15. Removing OpenVDB from Debian will affect Blender, which is is
relatively high-profile and should not just be axed for the sake if a pruning
operation.
You still have time, we aren't going to release the trix
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 l
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
Hi,
I believe this issue can be addressed by my proposed fix for #1063986:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063986#12
Regards,
Gregor
Hi,
I think this issue can be fixed by pulling in the latest sentry-sdk
version (1.43 at this point) and applying the following patch:
diff --git a/debian/rules b/debian/rules
index 206ab22..27d6911 100755
--- a/debian/rules
+++ b/debian/rules
@@ -43,6 +43,7 @@ PYBUILD_TEST_ARGS_PYTEST7_IGNOR
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, be
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 dependenc
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 u
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
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 b
(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!
Althoug
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
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
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
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 bui
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/c
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.
Thes
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
Su
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
Hi,
> fatal error: catch2/catch.hpp: No such file or directory
This is caused by significant changes in catch2 3.4.0.
Some other packages are affected by the same problem, which currently
blocks migration: https://qa.debian.org/excuses.php?package=catch2
I think this bug should be:
reassign
Package: 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
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
purelib: directory for site-specific, non-platform-specific files
(https://docs.python.org/3/library/sysconfig.html)
"site-specific" doesn't sound like packages should install anything
there.
"site-specific" may be meant from the perspective of the Python
interpreter, not the whole system, so
Source: uranium
Version: 5.0.0-2
Followup-For: Bug #1042157
X-Debbugs-Cc: onit...@gmail.com
This is caused by a change in cmake 3.27.
In 3.26.4-4, Python_SITELIB is /usr/lib/python3/dist-packages.
In 3.27.1-1, it's /usr/local/lib/python3.11/dist-packages
The documentation for 3.26 states:
> Inf
-- 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
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/
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
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
#
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 rep
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.
Hi myon,
I've tested the patch both on amd64 and i686 (in a chroot) and pushed it
to Salsa.
Could you upload cura-engine 5.0.0-4 when you have time?
Thank you very much!
Regards,
Gregor
This is actually a bug in the test and not CuraEngine.
In tests/InfillTest.cpp:104, they format a size_t as %lld instead of
%zu. %llu works as well, but it's not 100% correct with a 32-bit size_t.
Current upstream HEAD still has the bug, so I'm going to report it there
as well:
https://githu
Hi myon,
Cmake files check for matching architecture width now, mark package as Arch: any
* Cmake files check for matching architecture width now, mark package as
Arch: any. (The header files themselves do not change. Closes: #1040191)
* Drop M-A: foreign.
Thanks for the quick fix, but I'm
your package fails the autopkgtest with the new pytest 7.3 because
python/test/unit/function/test_function_space.py uses a bytes object
(b""" literal) as module docstring, and pytest crashes while looking for
the "PYTEST_DONT_REWRITE" marker.
This does sound like a serious bug in pytest, though.
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
line8.
@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
---
d
Package: firmware-linux-nonfree
Version: 20221214-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
With the recent upgrade to version 20230210 (or 20230117 on testing), the
package has vanished from the apt cache of two of my bookworm/sid
Is anybody already working on this?
I will attempt to fix d/copyright and submit a patch or MR for review
otherwise.
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/c2
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 wxWi
Prusa Slicer 2.5.0+dfsg-2 still SIGSEGV's during startup on Bookworm
with some sid.
A local rebuild does also runs into Segfault. However, it also reports
that it is unable to init glew.
I'm quite sure it is a different issue, but the result is quite the
same. So i was unsure if I should open a
Do you have a bit more context for this?
From the log, I can't see what the actual issue is.
Is it an autoconf check that fails or an actual compilation issue?
If it's a check, which one?
If it's actually in the source, the error doesn't make any sense.
Compilation is done without -Werror, and
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?
> 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)
> /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 th
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
s
> 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
> 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
> 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
> p
> https://salsa.debian.org/games-team/renpy/commit/fc29ebfe106238b590a7896450a5d1ad1f94f84e
>
>
> Switch to python3.
>
> Closes: #938351
>
I'm confuse
> 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::T
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.
> 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.
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
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 migrati
> > 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/
> 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 gsc
> 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
> 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 inclu
Looks like the dependency chain is fixed, python3-pyqt5 is installable again.
Thanks.
> 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
Descr
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 u
> 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: ht
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
contai
> 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.
>> 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/pkgconfi
>> 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
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.
> 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.
>
> Th
> 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 fo
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
> 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 k
Ok, it looks like I misunderstood how binNMUs work, so I'll simply prepare a
release then. [1]
[1] https://wiki.debian.org/binNMU
> 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&suite=unstable
>
> So far it only build fine only on these release architectures" arm
> 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 c
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 th
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
> 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 probl
> 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
> 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.
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
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
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 th
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.
1 - 100 of 108 matches
Mail list logo
