Re: Bug#1035387: csound: Regression from Bullseye: K opcodes not initialized at init time
On 5/2/23 17:55, Sam Hartman wrote: Package: csound Version: 1:6.18.1+dfsg-1 Tags: fixed-upstream, upstream See https://github.com/csound/csound/issues/1707 I'd like to NMU a fix once things settle down on the upstream side and I'd like to file an unblock request (or a stable update request if this misses the bookworm release). I'm not a member of the multimedia team, but I am familiar with the csound packaging. Are you okay with me doing an NMU and submitting a merge request on salsa once we settle on a fix on the upstream github issue? fine by me. gdmasr IOhannes OpenPGP_0xB65019C47F7A36F8.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Processed: bug 1035387 is forwarded to https://github.com/csound/csound/issues/1707
Processing commands for cont...@bugs.debian.org: > forwarded 1035387 https://github.com/csound/csound/issues/1707 Bug #1035387 [csound] csound: Regression from Bullseye: K opcodes not initialized at init time Set Bug forwarded-to-address to 'https://github.com/csound/csound/issues/1707'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1035387: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035387 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1035387: csound: Regression from Bullseye: K opcodes not initialized at init time
Package: csound Version: 1:6.18.1+dfsg-1 Tags: fixed-upstream, upstream See https://github.com/csound/csound/issues/1707 I'd like to NMU a fix once things settle down on the upstream side and I'd like to file an unblock request (or a stable update request if this misses the bookworm release). I'm not a member of the multimedia team, but I am familiar with the csound packaging. Are you okay with me doing an NMU and submitting a merge request on salsa once we settle on a fix on the upstream github issue? You can declare an opcode something like opcode inittest,K,0 According o the docs, the output parameter is copied both at k-time and at i-time. It turns out in csound 6.14 (bullseye) it's always copied at i-time even if declared as 'k' not 'K'. But that in 6.18 it's only copied as k-time. If you are using the opcode as a state machine, triggering reinits, etc, that can totally break your orchestra.
Bug#1034674: marked as done (mm3d can not load OBJ files, corrupts IQE & SMD & D3D files on save, depending on locale)
Your message dated Tue, 2 May 2023 15:20:43 +0200 with message-id <92841277-4c5e-9683-ef80-f3e28a144...@iem.at> and subject line mm3d cannot load OBJ files, depending on locale has caused the Debian Bug report #1034674, regarding mm3d can not load OBJ files, corrupts IQE & SMD & D3D files on save, depending on locale to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1034674: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034674 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: mm3d Version: 1.3.12-1+b1 Severity: grave Tags: l10n X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net Dear Maintainer, I tried to open some OBJ files with mm3d, but no 3D model was shown. I figured out that it seems to have something to do with my locale. I think file loading code mistakenly localizes decimal separators. This did not work: LC_NUMERIC=de_DE.UTF-8 mm3d tmp/sydney.obj This did work: LC_NUMERIC=C mm3d tmp/sydney.obj According to this commit message I found, this is fixed in a new upstream version: https://github.com/zturtleman/mm3d/commit/f00fdd5f2a27292a646a23ba34f80be50ab9844c The commit message also warns that mm3d will corrupt IQE & SMD & D3D when saving … for this reason the bug report is marked grave because this could cause data loss! -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/16 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mm3d depends on: ii libc6 2.31-13+deb11u5 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libgl1 1.3.2-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libqt5core5a5.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5opengl5 5.15.2+dfsg-9 ii libqt5widgets5 5.15.2+dfsg-9 ii libstdc++6 10.2.1-6 Versions of packages mm3d recommends: ii blender 2.83.5+dfsg-5+deb11u1 ii wings3d 2.2.5-1 pn yafray mm3d suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- the version currently in Debian/testing (aka bookworm) is 1.3.13-1, which has this bug already fixed. "bookworm" is now in deep freeze. thanks. OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Processed: fixed 1034674 in 1.3.13-1
Processing commands for cont...@bugs.debian.org: > fixed 1034674 1.3.13-1 Bug #1034674 [mm3d] mm3d can not load OBJ files, corrupts IQE & SMD & D3D files on save, depending on locale Marked as fixed in versions mm3d/1.3.13-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1034674: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034674 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1021601: vlc: VAAPI hardware acceleration no more available
On Sun, 05 Mar 2023 15:31:01 + bob_smith_1337 wrote: > This is also the case for me with VLC 3.0.18-2 (current debian bookworm version) > Is there any workaround ? > Thanks a lot I recovered VAAPI acceleration by downloading ffmpeg 4.4 on the ffmpeg website, and then compiling and installing it in /usr/local. Then I compiled VLC and it worked. Loss of VAAPI hw acceleration with ffmpeg 5.x has been reported to VLC devs, and it will _not_ be corrected in the 3.x branch. Cf. https://code.videolan.org/videolan/vlc/-/issues/26772 Have a good day. FM
Bug#1035367: libavcodec-dev ships headers that depend on windows d3d
Package: libavcodec-dev Version: 7:5.1.2-3 Severity: minor User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar Dear maintainers, As part of an investigation to establish the feasibility of moving 32-bit archs to 64-bit time_t, I am running an analysis of all header files in the archive to determine which libraries' ABIs are affected. This requires the headers in question to be compilable. libavcodec-dev ships header files which have includes that are not sanely satisfiable in Debian. (They are Windows-specific D3D headers, only available from wine; but referencing the wine implementation doesn't seem sane either.) For my purposes, I've worked around these unusable headers by adding quirks to my scripts, but it seems worth reporting as a bug that headers are being shipped that aren't usable. - libavcodec/d3d11va.h, which #includes d3d11.h - libavcodec/dxva2.h, which #includes d3d9.h - libavcodec/qsv.h depends on mfx/mfxvideo.h from libmfx-dev, which is amd64-only - libavcodec/vdpau.h depends on vdpau/vdpau.h from libvdpau-dev - libavcodec/videotoolbox.h depends on VideoToolbox/VideoToolbox.h, which does not exist in Debian -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
