Hi Tobias,
I've prepared an NMU for slic3r-prusa (versioned as 2.7.4+dfsg-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Thank you, but could you explain where this patch is coming from?
+ set(OCCT_LIBS
+-TKXDESTEP
+-TKSTEP
+-TKSTEP209
If a fix for this can't be released on time, I'm requesting an exception for
llvm-15. Removing OpenVDB from Debian will affect Blender, which is is
relatively high-profile and should not just be axed for the sake if a pruning
operation.
You still have time, we aren't going to release the
Which LLVM versions are you planning to remove?
15, 16 soon. 17 later.
Would it be possible to keep at least LLVM 15 until upstream has
upgraded their code base?
Sounds very unlikely for the next Debian release.
If a fix for this can't be released on time, I'm requesting an exception
for
As part of the effort to limit the number of llvm packages in the
archive, it would be great if you could upgrade to -17.
This package depends on 14.
Not possible at this time. Trying to build openvdb 10.0.1 against LLVM
17 results in the following error:
CMake Error at
Hi,
I believe this issue can be addressed by my proposed fix for #1063986:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063986#12
Regards,
Gregor
Hi,
I think this issue can be fixed by pulling in the latest sentry-sdk
version (1.43 at this point) and applying the following patch:
diff --git a/debian/rules b/debian/rules
index 206ab22..27d6911 100755
--- a/debian/rules
+++ b/debian/rules
@@ -43,6 +43,7 @@
Hi Timo,
This is not about Build-Depends, nor about the binary package Depends.
uranium has an explicit debian/tests/control file with "Depends: @",
which only installs the built package(s) and their dependencies. Up
until now, these dependencies included all supported Python
interpreters,
Hi Timo,
your package has an autopkgtest regression due to changes in NumPy.
The python3-numpy package no longer depends on all supported Python
versions. You need to depend on python3-all if you want to run your
tests against all supported Python releases.
Can you elaborate why this
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
Source: libbgcode
Version: 0.0~git20231219.7aaf717-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Usertags: s390x
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
buildd reports failing unit tests on s390x and ppc64: [1] [2]
Example error:
1: Filters: "File
Hi Graham,
sip4's autopkgtests fail with Python 3.12 [1]. I've copied what I
hope is the relevant part of the log below.
[1] https://ci.debian.net/packages/s/sip4/testing/amd64/
22s autopkgtest [20:09:51]: test autodep8-python3: [---
22s Testing with python3.12:
22s
22s
(sorry for the very late response, I only noticed your message just now)
I did come to the conclusion that Werkzeug 2.3.x has some bigger changes
that will break most of the existing packages in some way. The main
differences to Werkzeug 3.x than isn't that big.
Ok, that makes sense!
Hi Carsten,
I can see that 3.0.1 is currently in experimental, but it would be enough to
upgrade to the latest 2.x to fix this issue.
this makes not really sense to me. Flask 3.0.0 and Werkzeug 3.0.0 was
released on 09-30-2023, so almost three months before. Putting energy
into Flask 2.3.5
I don't see any other errors in the log except for the ast.Str
deprecation warnings, and they all come from python-werkezug and not
this package.
Reassiging the bug.
Upstream has already fixed this in in 2.3.5, by the way:
https://github.com/pallets/werkzeug/issues/2704
I can see that 3.0.1
Gah, looks like some arch-dependent glitch. Which explains why it didn't
happen to either of us (we probably both used amd64 machines, I
definitely did) and then the failure did happen upon publishing.
Thanks for your help, I'll try to help get the next fix in once it's ready.
Ok, so I have
Hi Aaron,
Simon is uploading the new packaging to the DELAYED/1 queue. It should
arrive in the archive on November 30.
If you are a maintainer of slic3r-prusa, you can review the new
packaging in the mean time and reject or fast-track it as you see fit.
Thanks a lot for this!
The NMU is
Here's the promised patch.
Also, I just found that this change was done in wxWidgets 3.2.4.
Upstream PR: https://github.com/wxWidgets/wxWidgets/pull/23309
It seems the wxWidgets developers actually recommend to move away from
wxArrayString and the like:
Source: slic3r-prusa
Version: 2.6.1+dfsg-4
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: onit...@gmail.com
Hi,
During a recent upload, PrusaSlicer failed to build due to incompatible chanes
in wxWidgets 3.2.
Here's an updated version of the patch with hardcoded precision values
replaced with the epsilon constant used in other unit tests.
I also submitted the patch as a PR upstream:
https://github.com/prusa3d/PrusaSlicer/pull/11576From: Gregor Riepl
Date: Tue, 31 Oct 2023 19:37:00 +0100
Subject
appropriate to me for what slic3r does. I
believe there is no change in correctness, the results should be well
within acceptable limits.
Regards,
GregFrom: Gregor Riepl
Date: Tue, 31 Oct 2023 19:37:00 +0100
Subject: Catch2 v3 updates
Bug-Debian: https://bugs.debian.org/1054697
---
tests
Hi,
> fatal error: catch2/catch.hpp: No such file or directory
This is caused by significant changes in catch2 3.4.0.
Some other packages are affected by the same problem, which currently
blocks migration: https://qa.debian.org/excuses.php?package=catch2
I think this bug should be:
reassign
Package: 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
purelib: directory for site-specific, non-platform-specific files
(https://docs.python.org/3/library/sysconfig.html)
"site-specific" doesn't sound like packages should install anything
there.
"site-specific" may be meant from the perspective of the Python
interpreter, not the whole system, so
Source: uranium
Version: 5.0.0-2
Followup-For: Bug #1042157
X-Debbugs-Cc: onit...@gmail.com
This is caused by a change in cmake 3.27.
In 3.26.4-4, Python_SITELIB is /usr/lib/python3/dist-packages.
In 3.27.1-1, it's /usr/local/lib/python3.11/dist-packages
The documentation for 3.26 states:
>
-- Installing:
/<>/debian/tmp/usr/local/lib/python3.11/dist-packages/UM
-- Installing:
/<>/debian/tmp/usr/local/lib/python3.11/dist-packages/UM/ColorImage.py
dh_install: warning: Cannot find (any matches for)
"usr/lib/python3/dist-packages/UM" (tried in ., debian/tmp)
dh_install:
Here's an excerpt of the failing tests:
test 21
Start 21: PolygonConnectorTest
21: Test command: cura-engine/obj-i686-linux-gnu/PolygonConnectorTest
21: Working Directory: cura-engine/tests/
21: Test timeout computed to be: 1500
5: [ OK ]
Source: cura-engine
Version: 5.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Usertags: i686
Forwarded: https://github.com/Ultimaker/CuraEngine/issues/1192
X-Debbugs-Cc: onit...@gmail.com
On i686, CuraEngine 5.x fails to build
Upstream has fixed this via
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5b429b870767e2107bcc7d5d849e04d6901b5912
Thanks for uploading the fix.
Unfortunately, it looks like the buildds are still choking on it:
https://buildd.debian.org/status/package.php?p=binutils-avr
#
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
The package fails to build in a test rebuild on at least amd64 with
gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
severity of this report will be raised before the trixie release.
This issue was due to a missing #include , and it was already
fixed upstream in an unrelated
Hi 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:
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,
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
.
@Milan please review the patch and push a new version soon, if you can.From acdcf1c29c6a3d3d20cac2d4cf046a5a0e7c90cf Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Sun, 19 Feb 2023 00:31:37 +0100
Subject: [PATCH] Fix and updat d/copyright to include all copyrights and
correct licenses
---
debian
Package: firmware-linux-nonfree
Version: 20221214-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
With the recent upgrade to version 20230210 (or 20230117 on testing), the
package has vanished from the apt cache of two of my bookworm/sid
Is anybody already working on this?
I will attempt to fix d/copyright and submit a patch or MR for review
otherwise.
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:
The wrong wxWidgets Version is linked during the build. Normally debian/rules
specifies WX_STABLE=1 which should result in the usage of wxWidgets 3.0 which
is in stable. However, wx-config always returns wx3.2 which is then used by
CMake even if CMakeLists.txt is changed to especially require
Prusa Slicer 2.5.0+dfsg-2 still SIGSEGV's during startup on Bookworm
with some sid.
A local rebuild does also runs into Segfault. However, it also reports
that it is unable to init glew.
I'm quite sure it is a different issue, but the result is quite the
same. So i was unsure if I should open a
Do you have a bit more context for this?
From the log, I can't see what the actual issue is.
Is it an autoconf check that fails or an actual compilation issue?
If it's a check, which one?
If it's actually in the source, the error doesn't make any sense.
Compilation is done without -Werror,
That seems to be a dead giveaway:
#2 0x7696e0c6 in wxTranslations::SetLanguage (this=0x0,
lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384
I'd expect it to crash when *this* is a null pointer.
Have you reported the issue upstream?
> Could NOT find TBB (missing: Tbb_INCLUDE_DIR) (Required is at least
> version
> "2018.0")
> Call Stack (most recent call first):
> /usr/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594
> (_FPHSA_FAILURE_MESSAGE)
> cmake/FindTBB.cmake:319
> /home/merkys/slic3r-prusa-2.4.2+dfsg/src/libslic3r/OpenVDBUtils.cpp:9:
> /usr/include/openvdb/tools/MeshToVolume.h:36:10: fatal error:
> tbb/task_scheduler_init.h: No such file or directory
>36 | #include
> | ^~~
> compilation terminated.
Looks like
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
> 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
> 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
>
> https://salsa.debian.org/games-team/renpy/commit/fc29ebfe106238b590a7896450a5d1ad1f94f84e
>
>
> Switch to python3.
>
> Closes: #938351
>
I'm
> 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
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.
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
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
> > 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:
> 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
> 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
> 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
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
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
> 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:
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
> 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
>> 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
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.
>
>
> 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
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
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=unstable
>
> So far it only build fine only on these release architectures" armel,
>
> 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
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
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
> 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
> 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:
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
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.
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
The upstream patch is contained in 1.0.0-rc3.
Please update the package as soon as possible.
Thank you!
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
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
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.
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
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
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
93 matches
Mail list logo
