RFS winff - GUI video and audio batch converter using ffmpeg
Dear Debian multimedia maintainers, Some time ago I packaged the program winff, which is a GUI for ffmpeg. It converts video/audio files into any other format that ffmpeg supports. It comes with a set of optimized conversion settings for different formats. I would like some people to have a look at the package and possibly sponsor it. I have asked at [EMAIL PROTECTED], but I got no response. I would also like to maintain this package in this team if that is possible. The homepage: http://www.winff.org The package: http://mentors.debian.net/debian/pool/main/w/winff A teaser: winff has been downloaded more than one million times. * Package name: winff Version : 0.42-1 Upstream Author : Matthew Weatherford <[EMAIL PROTECTED]> * URL : http://www.winff.org * License : GLP-3 Section : graphics winff - video and audio batch converter using ffmpeg WinFF is a graphical user interface for FFmpeg. It will convert almost any video file that FFmpeg will convert. WinFF does multiple files in multiple formats at one time. You can, for example, convert mpeg's, flv's, and mov's into avi's (or DVD/VCD format or MPEG or 3gp etc.) all at once. This package provides a variety of preset conversion settings for common formats and devices. These presets are intended to hit the "sweet spot" for each individual codec. They have been written with a tip of the balance to quality. It builds this binary package: winff - video and audio batch converter using ffmpeg The package appears to be lintian clean. The upload would fix these bugs: 485481 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/winff - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/w/winff/winff_0.42-1.dsc Please also reply to my private mail adres, I am not on this mail list. With kind regards, Paul signature.asc Description: OpenPGP digital signature
Bug#943900: twolame breaks ffmpeg autopkgtest: twolame_init_params(): 384kbps is an invalid bitrate for mono encoding.
Source: twolame, ffmpeg Control: found -1 twolame/0.4.0-2 Control: found -1 ffmpeg/7:4.2.1-1 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of twolame the autopkgtest of ffmpeg fails in testing when that autopkgtest is run with the binary packages of twolame from unstable. It passes when run with only packages from testing. In tabular form: passfail twolamefrom testing0.4.0-2 ffmpeg from testing7:4.2.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of twolame to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=twolame https://ci.debian.net/data/autopkgtest/testing/amd64/f/ffmpeg/3300508/log.gz Test 95: trying muxer 'asf' with 'a' encoder 'libtwolame' for codec 'mp2' ffmpeg -f lavfi -i sine=d=0.1 -strict -2 -c:a libtwolame -f asf /tmp/autopkgtest-lxc.m3tk853a/downtmp/autopkgtest_tmp/test/libtwolame.asf -y -hide_banner -nostdin Input #0, lavfi, from 'sine=d=0.1': Duration: N/A, start: 0.00, bitrate: 705 kb/s Stream #0:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s16le (native) -> mp2 (libtwolame)) twolame_init_params(): 384kbps is an invalid bitrate for mono encoding. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height Conversion failed! FAILED: asf;a=mp2:libtwolame; encoding return code: 1 signature.asc Description: OpenPGP digital signature
Bug#944017: libsoxr: autopkgtest regression: segmentation fault
Source: libsoxr Version: 0.1.3-2 Severity: serious X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of libsoxr the autopkgtest of libsoxr fails in testing when that autopkgtest is run with the binary packages of libsoxr from unstable. It passes when run with only packages from testing. In tabular form: passfail libsoxrfrom testing0.1.3-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libsoxr https://ci.debian.net/data/autopkgtest/testing/amd64/libs/libsoxr/3316475/log.gz autopkgtest [06:56:28]: test inst-check: [--- Examples in /usr/share/doc/libsoxr-dev/examples; using pkg-config: cc -o /tmp/tmp.8rTY2fUTZY/1-single-block 1-single-block.c -lsoxr -lm c++ -o /tmp/tmp.8rTY2fUTZY/2-stream 2-stream.C -lsoxr -lm cc -o /tmp/tmp.8rTY2fUTZY/3-options-input-fn 3-options-input-fn.c -lsoxr -lm cc -o /tmp/tmp.8rTY2fUTZY/4-split-channels 4-split-channels.c -lsoxr -lm cc -o /tmp/tmp.8rTY2fUTZY/5-variable-rate 5-variable-rate.c -lsoxr -lm 0.09 0.56 0.92 0.76 0.07 -0.71 -1.05 -0.72 0.03 0.73 0.99 0.69 -0.00 -0.69 -0.99 -0.72 -0.01 0.71 1.01 0.71 -0.00 -0.71 -1.00 -0.70 0.00 0.71 1.00 0.71 0.00 -0.71 -1.00 -0.71 0.00 0.71 1.00 0.71 -0.00 -0.71 -1.00 -0.71 -0.00 0.71 1.00 0.71 0.00 -0.71 -1.00 -0.71 -0.00 0.71 1.00 0.71 0.00 -0.71 -1.00 -0.71 0.00 0.71 1.00 0.71 0.00 -0.71 -1.00 -0.71 -0.00 0.71 1.00 0.71 -0.00 -0.71 -1.00 -0.71 -0.00 0.70 1.00 0.71 0.00 -0.71 -1.01 -0.71 0.01 0.72 0.99 0.69 0.00 -0.69 -0.99 -0.73 -0.03 0.72 1.05 0.71 -0.07 -0.76 -0.92 -0.56 /tmp/tmp.8rTY2fUTZY/1-single-block no error runtime=libsoxr-0.1.3 API=0.1.3 /tmp/tmp.8rTY2fUTZY/2-stream no error; I/O: no error /tmp/tmp.8rTY2fUTZY/3-options-input-fn no error; 0 clips; I/O: no error (cr32s) Segmentation fault autopkgtest [06:56:29]: test inst-check: ---] signature.asc Description: OpenPGP digital signature
Bug#946632: libkate: autopkgtest regression: tests removed executables
Source: libkate Version: 0.4.1-10 Severity: serious X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of libkate the autopkgtest of libkate fails in testing when that autopkgtest is run with the binary packages of libkate from unstable. It passes when run with only packages from testing. In tabular form: passfail libkatefrom testing0.4.1-10 all others from testingfrom testing I copied some of the output at the bottom of this report. It seems the autopkgtest tries to test binaries that were removed in the latest upload. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libkate https://ci.debian.net/data/autopkgtest/testing/amd64/libk/libkate/3642386/log.gz autopkgtest [04:12:56]: test test-cmd-tools: [--- /tmp/autopkgtest-lxc.r9twx9yv/downtmp/build.Ya8/src/debian/tests/test-cmd-tools: 25: kateenc: not found /tmp/autopkgtest-lxc.r9twx9yv/downtmp/build.Ya8/src/debian/tests/test-cmd-tools: 31: katalyzer: not found /tmp/autopkgtest-lxc.r9twx9yv/downtmp/build.Ya8/src/debian/tests/test-cmd-tools: 37: katedec: not found /tmp/autopkgtest-lxc.r9twx9yv/downtmp/build.Ya8/src/debian/tests/test-cmd-tools: 40: errorunable to run katedec: not found error: unable to run kateenc error: unable to run katalyser autopkgtest [04:12:57]: test test-cmd-tools: ---] signature.asc Description: OpenPGP digital signature
Bug#946917: muse FTBFS after libfluidsynth update
Source: muse Version: 3.0.2+ds1-1 Severity: serious Tags: ftbfs sid bullseye Justification: ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear maintainers, Your package is part of the libfluidsynth2 transition, so I scheduled binNMU's. However, your package FTBFS on all architectures. Please fix your package. Paul https://buildd.debian.org/status/package.php?p=muse Tail of log for muse on amd64: 153 | MidiPlayEvent(const MEvent& e) : MEvent(e) {} |^ /<>/muse/mpevent.h:68:15: note: because ‘MusECore::MEvent’ has user-provided ‘MusECore::MEvent& MusECore::MEvent::operator=(const MusECore::MEvent&)’ 68 | MEvent& operator=(const MEvent& ed) { | ^~~~ [ 66%] Linking CXX shared library libmuse_widgets.so cd /<>/obj-x86_64-linux-gnu/muse/widgets && /usr/bin/cmake -E cmake_link_script CMakeFiles/widgets.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -std=c++11 -Werror=format-security -Wextra -Winvalid-pch -fexceptions -Wall -fPIC -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -shared -Wl,-soname,libmuse_widgets.so -o libmuse_widgets.so CMakeFiles/widgets.dir/moc_aboutbox_impl.o CMakeFiles/widgets.dir/moc_arrangercolumns.o CMakeFiles/widgets.dir/moc_action.o CMakeFiles/widgets.dir/moc_bigtime.o CMakeFiles/widgets.dir/moc_canvas.o CMakeFiles/widgets.dir/moc_checkbox.o CMakeFiles/widgets.dir/moc_choose_sysex.o CMakeFiles/widgets.dir/moc_clipper_label.o CMakeFiles/widgets.dir/moc_colorframe.o CMakeFiles/widgets.dir/moc_comboQuant.o CMakeFiles/widgets.dir/moc_combobox.o CMakeFiles/widgets.dir/moc_comment.o CMakeFiles/widgets.dir/moc_compact_knob.o CMakeFiles/widgets.dir/moc_compact_patch_edit.o CMakeFiles/widgets.dir/moc_compact_slider.o CMakeFiles/widgets.dir/moc_copy_on_write.o CMakeFiles/widgets.dir/moc_cpu_toolbar.o CMakeFiles/widgets.dir/moc_ctrlcombo.o CMakeFiles/widgets.dir/moc_custom_widget_actions.o CMakeFiles/widgets.dir/moc_dentry.o CMakeFiles/widgets.dir/moc_didyouknow.o CMakeFiles/widgets.dir/moc_doublelabel.o CMakeFiles/widgets.dir/moc_doublespinbox.o CMakeFiles/widgets.dir/moc_editevent.o CMakeFiles/widgets.dir/moc_elided_label.o CMakeFiles/widgets.dir/moc_filedialog.o CMakeFiles/widgets.dir/moc_genset.o CMakeFiles/widgets.dir/moc_mdisettings.o CMakeFiles/widgets.dir/moc_header.o CMakeFiles/widgets.dir/moc_hitscale.o CMakeFiles/widgets.dir/moc_intlabel.o CMakeFiles/widgets.dir/moc_knob.o CMakeFiles/widgets.dir/moc_knob_and_meter.o CMakeFiles/widgets.dir/moc_lcd_widgets.o CMakeFiles/widgets.dir/moc_lcombo.o CMakeFiles/widgets.dir/moc_line_edit.o CMakeFiles/widgets.dir/moc_menutitleitem.o CMakeFiles/widgets.dir/moc_meter.o CMakeFiles/widgets.dir/moc_meter_slider.o CMakeFiles/widgets.dir/moc_metronome.o CMakeFiles/widgets.dir/moc_midi_audio_control.o CMakeFiles/widgets.dir/moc_midisyncimpl.o CMakeFiles/widgets.dir/moc_midi_warn_init_pending_impl.o CMakeFiles/widgets.dir/moc_mixdowndialog.o CMakeFiles/widgets.dir/moc_mlabel.o CMakeFiles/widgets.dir/moc_mtscale.o CMakeFiles/widgets.dir/moc_mtscale_flo.o CMakeFiles/widgets.dir/moc_nentry.o CMakeFiles/widgets.dir/moc_noteinfo.o CMakeFiles/widgets.dir/moc_pastedialog.o CMakeFiles/widgets.dir/moc_pasteeventsdialog.o CMakeFiles/widgets.dir/moc_pitchedit.o CMakeFiles/widgets.dir/moc_pitchlabel.o CMakeFiles/widgets.dir/moc_pixmap_button.o CMakeFiles/widgets.dir/moc_plugindialog.o CMakeFiles/widgets.dir/moc_popup_double_spinbox.o CMakeFiles/widgets.dir/moc_popupmenu.o CMakeFiles/widgets.dir/moc_poslabel.o CMakeFiles/widgets.dir/moc_projectcreateimpl.o CMakeFiles/widgets.dir/moc_routepopup.o CMakeFiles/widgets.dir/moc_scroll_area.o CMakeFiles/widgets.dir/moc_scrollbar.o CMakeFiles/widgets.dir/moc_scrollscale.o CMakeFiles/widgets.dir/moc_shortcutcapturedialog.o CMakeFiles/widgets.dir/moc_shortcutconfig.o CMakeFiles/widgets.dir/moc_siglabel.o CMakeFiles/widgets.dir/moc_sigscale.o CMakeFiles/widgets.dir/moc_sig_tempo_toolbar.o CMakeFiles/widgets.dir/moc_slider.o CMakeFiles/widgets.dir/moc_sliderbase.o CMakeFiles/widgets.dir/moc_songinfo.o CMakeFiles/widgets.dir/moc_songpos_toolbar.o CMakeFiles/widgets.dir/moc_spinbox.o CMakeFiles/widgets.dir/moc_spinboxFP.o CMakeFiles/widgets.dir/moc_splitter.o CMakeFiles/widgets.dir/moc_swidget.o CMakeFiles/widgets.dir/moc_tb1.o CMakeFiles/widgets.dir/moc_tempolabel.o CMakeFiles/widgets.dir/moc_text_edit.o CMakeFiles/widgets.dir/moc_tools.o CMakeFiles/widgets.dir/moc_trackinfo_layout.o CMakeFiles/widgets.dir/moc_tracks_duplicate.o CMakeFiles/widgets.dir/moc_ttoolbutton.o CMakeFiles/widgets.dir/moc_unusedwavefiles.o CMakeFiles/widgets.dir/moc_view.o CMakeFiles/widgets.dir/moc_vscale.o CMakeFiles/widgets.dir/moc_visibletracks.o CMakeFiles/widgets.dir/moc_vst_native_editor.o CMakeFiles/widgets.dir/moc_warn_bad_timing.o CMakeFiles/widgets.dir/moc_widget_stack.o CMakeFiles/widgets
Bug#946920: vlc FTBFS after libfluidsynth update
Source: vlc Version: 3.0.8-3 Severity: serious Tags: ftbfs sid bullseye Justification: ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear maintainers, Your package is part of the libfluidsynth2 transition, so I scheduled binNMU's. However, your package FTBFS on all architectures. Please fix your package. Paul https://buildd.debian.org/status/package.php?p=vlc Tail of log for vlc on amd64: 878 | msleep( 4 ); | ^~ make[6]: Leaving directory '/<>/modules' make[5]: *** [Makefile:27485: all-recursive] Error 1 make[5]: Leaving directory '/<>/modules' make[4]: *** [Makefile:12539: all] Error 2 make[4]: Leaving directory '/<>/modules' make[3]: *** [Makefile:1553: all-recursive] Error 1 make[3]: Leaving directory '/<>' make[2]: *** [Makefile:1438: all] Error 2 make[2]: Leaving directory '/<>' dh_auto_build: make -j4 returned exit code 2 make[1]: *** [debian/rules:280: override_dh_auto_build] Error 255 make[1]: Leaving directory '/<>' make: *** [debian/rules:271: binary-arch] Error 2 - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvlc-bin depends on: ii libc62.29-3 ii libvlc5 3.0.8-3+b1 Versions of packages libvlc5 depends on: ii libc62.29-3 ii libvlccore9 3.0.8-3+b1 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.8-3+b1 Versions of packages vlc-bin depends on: ii libc6 2.29-3 ii libvlc-bin 3.0.8-3+b1 ii libvlc5 3.0.8-3+b1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-20 ii libaom0 1.0.0.errata1-2 ii libarchive13 3.4.0-1+b1 ii libaribb24-0 1.0.3-2 ii libasound2 1.1.9-1 ii libass9 1:0.14.0-2 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libavc1394-0 0.5.4-5 ii libavcodec58 7:4.2.1-2 ii libavformat587:4.2.1-2 ii libavutil56 7:4.2.1-2 ii libbasicusageenvironment12018.11.26-1.1+b1 ii libbluray2 1:1.1.2-2 ii libc62.29-3 ii libcairo21.16.0-4 ii libcddb2 1.3.2-6+b1 ii libchromaprint1 1.4.3-3 ii libdbus-1-3 1.12.16-2 ii libdc1394-22 2.2.5-2.1 ii libdca0 0.0.6-1 ii libdvbpsi10 1.3.3-1 ii libdvdnav4 6.0.1-1+b1 ii libdvdread7 6.0.2-2 ii libebml4v5 1.3.9-2 ii libfaad2 2.9.1-1 ii libflac8 1.3.3-1 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libfribidi0 1.0.7-1.1 ii libgcc1 1:9.2.1-21 ii libgcrypt20 1.8.5-3 ii libglib2.0-0 2.62.3-2 ii libgnutls30 3.6.10-5 ii libgpg-error01.36-7 ii libgroupsock82018.11.26-1.1+b1 ii libharfbuzz0b2.6.4-1 ii libixml101:1.8.4-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libkate1 0.4.1-9 ii liblirc-client0 0.10.1-6 ii liblivemedia64 2018.11.26-1.1+b1 ii liblua5.2-0 5.2.4-1.1+b3 ii libmad0 0.15.1b-10 ii libmatroska6v5 1.5.2-2 ii libmicrodns0 0.1.0-2 ii libmpcdec6 2:0.1~r495-2 ii libmpeg2-4 0.5.1-9 ii libmpg123-0 1.25.13-1 ii libmtp9 1.1.16-2 ii libncursesw6 6.1+20191019-1 ii libnfs13 4.0.0-1 ii libogg0 1.3.2-1+b1 ii libopenmpt-modplug1 0.4.10-1 ii libopus0 1.3-1+b1 ii libpng16-16 1.6.37-1 ii libpostproc557:4.2.1-2 ii libprotobuf-lite17 3.6.1.3-2+b1 ii libpulse013.0-3 ii libraw1394-11
Bug#947723: devede BD on python-scour which isn't build anymore and isn't in sid/bullseye
Source: devede Version: 4.15.0-1 Severity: serious Tags: ftbfs sid bullseye Dear maintainer, Recently the scour package has stopped building the python-scour package. This is an issue for your package as it build-depends on it. Please update the building of your package. Unfortunately the migration software doesn't detected this kind of situation yet, so your package FTBFS in sid and bullseye. Paul signature.asc Description: OpenPGP digital signature
Re: Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1
Hi Otto, kodi maintainers, On 02-02-2020 11:56, Otto Kekäläinen wrote: > Ok, I will amend the changelog and re-upload today 1:10.3.22-0... to > buster updates. The autopkgtest of kodi fails on ppc64el (twice) with the p-u version of MariaDB, while it passes with the old MariaDB version. I'll retrigger it for the third time, but maybe you want to have a look already. Paul [stable result] https://ci.debian.net/user/britney/jobs?package=kodi&trigger=mariadb-10.3&suite%5B%5D=stable&arch%5B%5D=arm64&arch%5B%5D=ppc64el [failing log] https://ci.debian.net/data/autopkgtest/stable/ppc64el/k/kodi/4212994/log.gz autopkgtest [20:24:43]: test gui: [--- tail: cannot open '/home/debci/.kodi/temp/kodi.log' for reading: No such file or directory tail: no files remaining autopkgtest [20:24:49]: test gui: ---] signature.asc Description: OpenPGP digital signature
Re: Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1
Hi Otto, On 06-02-2020 14:10, Otto Kekäläinen wrote: >> tail: cannot open '/home/debci/.kodi/temp/kodi.log' for reading: No such >> file or directory >> tail: no files remaining > > This is the only output in the test log, otherwise it is installing > packages and everything else seemed to go fine. > > Test source says it just starts the app, but now it does not seem to > output anything: > https://salsa.debian.org/multimedia-team/kodi/blob/master/debian/tests/gui Yes, and I am worried about that. If the MariaDB upgrade causes kodi to not run, that's a bad regression, don't you think? kodi has a pretty good history in Ubuntu on ppc64el, so I don't expect it to be flaky at first sight. Paul signature.asc Description: OpenPGP digital signature
Re: Bug#950272: buster-pu: package mariadb-10.3 10.3.22-0+deb10u1
Hi all, On 06-02-2020 15:11, Paul Gevers wrote: > Yes, and I am worried about that. If the MariaDB upgrade causes kodi to > not run, that's a bad regression, don't you think? > > kodi has a pretty good history in Ubuntu on ppc64el, so I don't expect > it to be flaky at first sight. I'm unhappy with the result, but the reference run with the old MariaDB now fails as well, so, no regression. I'm not sure what this means for kodi on ppc64el though. Paul signature.asc Description: OpenPGP digital signature
Bug#953707: src:libsoxr: fails to migrate to testing for too long
Source: libsoxr Version: 0.1.3-1 Severity: serious Control: fixed -1 0.1.3-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:libsoxr in its current version in unstable has been trying to migrate for 143 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have marked the version in unstable as fixing this bug, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=libsoxr signature.asc Description: OpenPGP digital signature
Bug#946104: rtkit: flaky autopkgtest: Input/output error
Control: severity -1 serious Control: user debian...@lists.debian.org Control: usertags -1 flaky Dear maintainer(s), Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Please either fix the test to be more robust, or or use the "flaky" restriction for the offending test until a solution has been found. I'll have the migration software ignore the results of your autopkgtest on arm64 until this bug is fixed. Paul signature.asc Description: OpenPGP digital signature
Bug#958416: src:olive-editor: fails to migrate to testing for too long
Source: olive-editor Version: 2019-1 Severity: serious Control: close -1 20200210-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 950564 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:olive-editor in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=olive-editor signature.asc Description: OpenPGP digital signature
Bug#960128: csound: autopkgtest regression: libcsound64.so: cannot open shared object file
Source: csound Version: 1:6.14.0~dfsg-2 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of csound the autopkgtest of csound fails in testing when that autopkgtest is run with the binary packages of csound from unstable. It passes when run with only packages from testing. In tabular form: passfail csound from testing1:6.14.0~dfsg-2 versioned deps [0 from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=csound https://ci.debian.net/data/autopkgtest/testing/amd64/c/csound/5391643/log.gz autopkgtest [07:07:45]: test python3-csound: [--- Testing ctcsound with python3.8: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/ctcsound.py", line 39, in libcsound = ct.CDLL("libcsound64.so") File "/usr/lib/python3.8/ctypes/__init__.py", line 373, in __init__ self._handle = _dlopen(self._name, mode) OSError: libcsound64.so: cannot open shared object file: No such file or directory autopkgtest [07:07:46]: test python3-csound: ---] signature.asc Description: OpenPGP digital signature
Bug#963153: ffmpeg breaks r-cran-av autopkgtest: error in 'avcodec_open2 (audio)': Invalid argument
Source: ffmpeg, r-cran-av Control: found -1 ffmpeg/7:4.3-2 Control: found -1 r-cran-av/0.5.0+dfsg-3 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of ffmpeg the autopkgtest of r-cran-av fails in testing when that autopkgtest is run with the binary packages of ffmpeg from unstable. It passes when run with only packages from testing. In tabular form: passfail ffmpeg from testing7:4.3-2 r-cran-av from testing0.5.0+dfsg-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ffmpeg to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ffmpeg https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-av/5951260/log.gz autopkgtest [13:08:56]: test run-unit-test: [--- BEGIN TEST testthat.R R version 4.0.1 (2020-06-06) -- "See Things Now" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > library(testthat) > library(av) > > if (ps::ps_is_supported()) { + reporter <- ps::CleanupReporter(testthat::CheckReporter)$new(proc_cleanup = FALSE, proc_fail = FALSE) + test_check("av", reporter = reporter) + } else { + test_check("av") + } Estimating duration from bitrate, this may be inaccurate Specified sample rate 8000 is not supported ── 1. Error: Audio FFT (@test-fft.R#10) ─── FFMPEG error in 'avcodec_open2 (audio)': Invalid argument Backtrace: 1. av::av_audio_convert(wonderland, filename, verbose = FALSE) Estimating duration from bitrate, this may be inaccurate ══ testthat results ═══ [ OK: 130 | SKIPPED: 0 | WARNINGS: 0 | FAILED: 1 ] 1. Error: Audio FFT (@test-fft.R#10) Error: testthat unit tests failed Execution halted autopkgtest [13:09:08]: test run-unit-test: ---] signature.asc Description: OpenPGP digital signature
Bug#934242: crystalhd: unusable without (available and properly working) firmware
Hi Jonas, [Release Team member watching] On Thu, 08 Aug 2019 17:37:35 +0200 Jonas Smedegaard wrote: > Source: crystalhd > Version: 1:0.0~git20110715.fdd2f19-1 > Severity: grave > Justification: renders package unusable > > It seems that libcrystalhd3 is only really useful together with > firmware-crystalhd, which was never really usable in Debian, leading to > that package being dropped: https://bugs.debian.org/865978 > > If someone wants to revive CrystalHD in Debian, it seems a good place to > start is https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update Can you elaborate a bit? The package has a huge popcon (hence it's not autoremoved). You're saying that all those people had it installed in vain? Or is that due to a (past) library dependency and didn't it actually add anything? elbrus@coccia:~$ dak rm --no-action -R --suite testing crystalhd Will remove the following packages from testing: crystalhd | 1:0.0~git20110715.fdd2f19-13 | source gstreamer1.0-crystalhd | 1:0.0~git20110715.fdd2f19-13 | amd64, i386 libcrystalhd-dev | 1:0.0~git20110715.fdd2f19-13 | amd64, i386 libcrystalhd3 | 1:0.0~git20110715.fdd2f19-13 | amd64, i386 Maintainer: Debian Multimedia Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Depends: kylin-video: kylin-video [amd64 i386] # Broken Build-Depends: kylin-video: libcrystalhd-dev Dependency problem found. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#934242: crystalhd: unusable without (available and properly working) firmware
affects 934242 src:kylin-video user release.debian@packages.debian.org usertag 934242 bullseye-will-remove Hi, On 21-12-2020 23:32, Jonas Smedegaard wrote: > Yes, there are still packages depending on it: Someone needs to work > actively with those still believing the library is more than snakeoil - > because our mechanisms auto-pressuring packages to to stay alert and in > line or else get kicked from testing works only on edge packages - > packages "well connected" in Debian are not affected. > > (while the allegory is funny, I really don't mean to imply that the > mechanisms were _intented_ to treat packages unequally, only that in > effect it does) So, let's inform the kylin-video team that we're about to remove crystalhd from bullseye. @kylin-video team, please drop your Build-Depends on libcrystalhd-dev and your Depends on libcrystalhd3. If this doesn't happen in a week or two, kylin-video will be removed from bullseye too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#979272: src:olive-editor: fails to migrate to testing for too long: FTBFS on arm64
Source: olive-editor Version: 20200528-1 Severity: serious Control: close -1 20200620-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 976515 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:olive-editor in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=olive-editor OpenPGP_signature Description: OpenPGP digital signature
Bug#979620: sonic-pi: flaky armhf and arm64 autopkgtest on ci.debian.net: unknown bpm
Source: sonic-pi Version: 3.2.2~repack-6 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), The autopkgtest of your package turned up as blocking xorg-server. I looked into the history of your autopkgtest and it fails regularly on arm64 and armhf [1, 2]. I copied some of the output at the bottom of this report. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Please do get in touch if we need to dive into this together. Or if you want to discuss this issue. Paul [1] https://ci.debian.net/packages/s/sonic-pi/testing/arm64/ [2] https://ci.debian.net/packages/s/sonic-pi/testing/armhf/ https://ci.debian.net/data/autopkgtest/testing/arm64/s/sonic-pi/9392735/log.gz Source: sonic-pi Version: 3.2.2~repack-6 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), The autopkgtest of your package turned up as blocking xorg-server. I looked into the history of your autopkgtest and it fails regularly on arm64 and armhf [1, 2]. I copied some of the output at the bottom of this report. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Please do get in touch if we need to dive into this together. Or if you want to discuss this issue. Paul [1] https://ci.debian.net/packages/s/sonic-pi/testing/arm64/ [2] https://ci.debian.net/packages/s/sonic-pi/testing/armhf/ https://ci.debian.net/data/autopkgtest/testing/arm64/s/sonic-pi/9392735/log.gz [32mBuffer: 4.03s./4.03sTime: 0.09m. DHP: [ ] Overruns: 0 Xruns: 0[0m [3A[0m[36m00:| | 01:| | [32mBuffer: 4.03s./4.03sTime: 0.09m. DHP: [ ] Overruns: 0 Xruns: 0[0m [3A[0m[36m00:| | 01:| | [32mBuffer: 4.03s./4.03sTime: 0.09m. DHP: [ ] Overruns: 0 Xruns: 0[0m [3A[0m[1A[31m [1A>>> Please wait while writing all data to disk. (shouldn't take long) [36m |"| [0m[36m00:| | 01:| | [32mBuffer: 4.05s./4.05sTime: 0.10m. DHP: [ ] Overruns: 0 Xruns: 0[0m [3A[0m[36m00:| | 01:| | [32mBuffer: 4.05s./4.05sTime: 0.10m. DHP: [ ] Overruns: 0 Xruns: 0[0m [31mFinished.[0m unknown bpm autopkgtest [17:56:12]: test gui: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#953289: ABI change in libsoxr 0.1.3
Hi all, On Sat, 7 Mar 2020 09:57:02 +0100 Max Kellermann wrote: > Package: libsoxr0 > Version: 0.1.3-2 > > In version 0.1.3, libsoxr has made an undocumented ABI change which > causes MPD (Music Player Daemon) to crash: > > https://github.com/MusicPlayerDaemon/MPD/issues/773 > > The commit which changed the ABI was: > > https://sourceforge.net/p/soxr/code/ci/52888cd410ae356bf3aa26d8fa106754b8fd8990 Any progress here? The transition freeze already started. How do you propose we solve this issue? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bits from the Debian Multimedia Maintainers
> Debian Multimedia Blend > ~~~ > > There is also an effort to start a Debian Multimedia Blend to give a > better overview about what multimedia applications are available in > Debian. There is a short list[2] for a quick overview as well as a long > package list separated in sections to give a more detailed overview > (including translations, screenshots, popularity of package etc)[3]. You > are invited to help improving the tasks either directly in SVN[4] or by > sending patches to Andreas Tille or > debian-multimedia@lists.debian.org (see below). Note that not all of the > packages listed in the tasks pages are maintained by the Debian > Multimedia team, since they are aimed at producing useful package sets > instead of showing only our own packages. As the maintainer of Winff I wondered if you guys (m/f) also considered winff for the multimedia blend? It is a simple GUI for ffmpeg and I would say useful for quick conversion of movies to (possible user) predefined settings. Paul signature.asc Description: OpenPGP digital signature
Bug#981871: src:bambootracker: fails to migrate to testing for too long: FTBFS on 32 bit
Source: bambootracker Version: 0.4.2-1 Severity: serious Control: close -1 0.4.5+git20121209-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 974580 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:bambootracker has been trying to migrate for 84 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=bambootracker OpenPGP_signature Description: OpenPGP digital signature
Bug#982034: forked-daapd: autopkgtest regression in testing: Job for forked-daapd.service failed.
Source: forked-daapd Version: 26.4+dfsg1-2 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent change somewhere outside of your package the autopkgtest of your package started to fail. I copied some of the output at the bottom of this report. Can you please investigate the situation and fix it? As a service, I have also generated a diff between the installed packages during the test of the last successful run on amd64 and the first that failed. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/testing/amd64/f/forked-daapd/10113463/log.gz autopkgtest [22:13:27]: test basic: [--- Job for forked-daapd.service failed. See "systemctl status forked-daapd.service" and "journalctl -xe" for details. autopkgtest [22:13:30]: test basic: ---] paul@mulciber /tmp $ diff -u passed/testbed-packages failed/testbed-packages --- passed/testbed-packages 2020-11-19 22:54:43.0 +0100 +++ failed/testbed-packages 2020-11-27 03:18:26.0 +0100 @@ -6,7 +6,7 @@ binutils 2.35.1-2 binutils-common2.35.1-2 binutils-x86-64-linux-gnu 2.35.1-2 -bsdutils 1:2.36-3+b2 +bsdutils 1:2.36.1-1 bzip2 1.0.8-4 coreutils 8.32-4+b1 dash 0.5.11+git20200708+dd9ef66-2 @@ -17,7 +17,7 @@ dialog 1.3-20190808-1 diffutils 1:3.7-3 dirmngr2.2.20-1 -dmsetup2:1.02.171-3 +dmsetup2:1.02.173-1 dpkg 1.20.5 dpkg-dev 1.20.5 e2fsprogs 1.45.6-1 @@ -40,8 +40,8 @@ gzip 1.10-2 hostname 3.23 ifupdown 0.8.36 -init 1.58 -init-system-helpers1.58 +init 1.59 +init-system-helpers1.59 iproute2 5.9.0-1 isc-dhcp-client4.4.1-2.1+b2 libacl12.2.53-8 @@ -53,7 +53,7 @@ libaudit-common1:2.8.5-3.1 libaudit1 1:2.8.5-3.1 libbinutils2.35.1-2 -libblkid1 2.36-3+b2 +libblkid1 2.36.1-1 libbsd00.10.0-1 libbz2-1.0 1.0.8-4 libc-bin 2.31-4 @@ -71,7 +71,7 @@ libdb5.3 5.3.28+dfsg1-0.6 libdbus-1-31.12.20-1 libdebconfclient0 0.255 -libdevmapper1.02.1 2:1.02.171-3 +libdevmapper1.02.1 2:1.02.173-1 libdns-export1110 1:9.11.19+dfsg-1 libdpkg-perl 1.20.5 libeatmydata1 105-9 @@ -85,27 +85,27 @@ libgcrypt201.8.7-2 libgdbm-compat41.18.1-5.1 libgdbm6 1.18.1-5.1 -libgmp10 2:6.2.0+dfsg-6 +libgmp10 2:6.2.1+dfsg-1 libgnutls303.6.15-4 libgpg-error0 1.38-2 -libgssapi-krb5-2 1.17-10 +libgssapi-krb5-2 1.18.3-4 libhogweed63.6-2 -libidn2-0 2.3.0-3 +libidn2-0 2.3.0-4 libip4tc2 1.8.6-1 libisc-export1105 1:9.11.19+dfsg-1 libjson-c5 0.15-1 -libk5crypto3 1.17-10 +libk5crypto3 1.18.3-4 libkeyutils1 1.6.1-2 libkmod2 27+20200310-2 -libkrb5-3 1.17-10 -libkrb5support01.17-10 +libkrb5-3 1.18.3-4 +libkrb5support01.18.3-4 libksba8 1.4.0-2 libldap-2.4-2 2.4.56+dfsg-1 libldap-common 2.4.56+dfsg-1 liblz4-1 1.9.2-2 liblzma5 5.2.4-1+b1 libmnl01.0.4-3 -libmount1 2.36-3+b2 +libmount1 2.36.1-1 libncurses66.2+20200918-1 libncursesw6 6.2+20200918-1 libnettle8 3.6-2 @@ -117,7 +117,7 @@ libpam-modules 1.3.1-5 libpam-modules-bin 1.3.1-5 libpam-runtime 1.3.1-5 -libpam-systemd 246.6-2 +libpam-systemd 246.6-4 libpam0g 1.3.1-5 libpcre2-8-0 10.34-7 libpcre3 2:8.39-13 @@ -133,19 +133,19 @@ libsemanage-common 3.1-1 libsemanage1 3.1-1+b1 libsepol1 3.1-1 -libsmartcols1 2.36-3+b2 +libsmartcols1 2.36.1-1 libsqlite3-0 3.33.0-1 libss2 1.45.6-1 libssl1.1 1.1.1h-1 libstdc++6 10.2.0-16 -libsystemd0246.6-2 +libsystemd0246.6-4 libtasn1-6 4.16.0-2 libtinfo6 6.2+20200918-1 libtirpc-common1.2.6-3 libtirpc3 1.2.6-3 -libudev1 246.6-2 +libudev1 246.6-4 libunistring2 0.9.10-4 -libuuid1 2.36-3+b2 +libuuid1 2.36.1-1 libwrap0 7.6.q-31 libxtables12 1.8.6-1 libzstd1 1.4.5+dfsg-4 @@ -155,7 +155,7 @@ lsb-base 11.1.0 make 4.3-4 mawk 1.3.4.20200120-2 -mount 2.36-3+b2 +mount 2.36.1-1 ncurses-base 6.2+20200918-1 ncurses-bin6.2+20200918-1 net-tools 1.60+git20181103.0eebece-1 @@ -173,16 +173,16 @@ python3-minimal3.8.6-1 python3.8-minimal 3.8.6-1 readline-common8.1~rc2-2 -runit-helper 2.9.0 +runit-helper 2.10.2 sed4.7-1 sensible-utils 0.0.12+nmu1 -systemd246.6-2 -systemd-sysv 246.6-2 -systemd-timesyncd 246.6-2 +systemd246.6-4 +systemd-sysv 246.6-4 +systemd-timesyncd 246.6-4 sysvinit-utils 2.96-5 tar1.30+dfsg-7 tzdata 2020d-1 ucf3.0043 -util-linux 2.36-3+b2 +util-linux 2.36.1-1 xz-utils 5.2.4-1+b1 zlib1g 1:1.2.11.dfsg-2 paul@mulci
Bug#1000702: src:sonic-visualiser: fails to migrate to testing for too long: FTBFS on armel and mipsel
Source: sonic-visualiser Version: 4.2-1 Severity: serious Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:sonic-visualiser has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package FTBFS on armel and mipsel. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=sonic-visualiser OpenPGP_signature Description: OpenPGP digital signature
Bug#1000702: closed by Debian FTP Masters (reply to IOhannes m zmölnig (Debian/GNU) ) (Bug#1000702: fixed in sonic-visualiser 4.4-2)
Hi IOhannes, On 27-11-2021 22:51, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:sonic-visualiser package: #1000702: src:sonic-visualiser: fails to migrate to testing for too long: FTBFS on armel and mipsel It seems that one of the tests has a rather strict timeout (or a real issue of course). The package still fails on armel (and hppa, riscv64 and sparc64) on: 4/4 svcore-data-fileio TIMEOUT30.05s killed by signal 6 SIGABRT Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001428: python-pyknon: (autopkgtest) needs update for python3.10: module 'collections' has no attribute 'MutableSequence'
Source: python-pyknon Version: 1.2-3 Severity: serious X-Debbugs-CC: debian...@lists.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.10 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.10 to the supported Python versions [0]. With a recent upload of python3-defaults the autopkgtest of python-pyknon fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.9.8-1 python-pyknon from testing1.2-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.10.html lists what's new in Python3.10, it may help to identify what needs to be updated. https://docs.python.org/3.9/library/collections.html says: """ Deprecated since version 3.3, will be removed in version 3.10: Moved Collections Abstract Base Classes to the collections.abc module. For backwards compatibility, they continue to be visible in this module through Python 3.9. """ Time to move on. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/996584 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pyknon/17420665/log.gz + cp -r test /tmp/autopkgtest-lxc.1rlw27co/downtmp/autopkgtest_tmp + cd /tmp/autopkgtest-lxc.1rlw27co/downtmp/autopkgtest_tmp/test/ + export PYTHONWARNINGS=d + py3versions -i + python3.10 -m pytest -rsx -v = test session starts == platform linux -- Python 3.10.1, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 -- /usr/bin/python3.10 cachedir: .pytest_cache rootdir: /tmp/autopkgtest-lxc.1rlw27co/downtmp/autopkgtest_tmp/test collecting ... collected 53 items / 2 errors / 51 selected ERRORS ___ ERROR collecting test_genmidi.py ___ test_genmidi.py:4: in from pyknon.genmidi import Midi, MidiError /usr/lib/python3/dist-packages/pyknon/genmidi.py:2: in from pyknon.music import Note, NoteSeq, Rest /usr/lib/python3/dist-packages/pyknon/music.py:106: in class NoteSeq(collections.MutableSequence): E AttributeError: module 'collections' has no attribute 'MutableSequence' ERROR collecting test_music.py test_music.py:2: in from pyknon.music import MusiclibError, Note, NoteSeq, Rest /usr/lib/python3/dist-packages/pyknon/music.py:106: in class NoteSeq(collections.MutableSequence): E AttributeError: module 'collections' has no attribute 'MutableSequence' !!! Interrupted: 2 errors during collection == 2 errors in 0.16s === autopkgtest [13:32:58]: test python3-pyknon OpenPGP_signature Description: OpenPGP digital signature
Bug#1073076: pd-iemmatrix: autopkgtest regression on s390x: failing test doesn't stop
Source: pd-iemmatrix Version: 0.4.0-1 Severity: important User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it failed to fail nicely on s390x today, triggered by an upload of puredata. The s390x host that we use for ci.d.n was running out of disk space multiple times today and I debugged it down that the culprit is pd-iemmatrix. When I manually start the test on testing with """ root@ci-worker-s390x-01:~# /usr/bin/autopkgtest --no-built-binaries --timeout=30600 --user debci --apt-upgrade --pin-packages=unstable=src:puredata '--add-apt-source=deb-src http://deb.debian.org/debian unstable main contrib non-free non-free-firmwaredeb http://deb.debian.org/debian unstable main contrib non-free non-free-firmware' pd-iemmatrix -- lxc --sudo --name elbrus autopkgtest-testing-s390x """ I see a file appearing in /tmp/autopkgtest-lxc.3gwldww1/downtmp/build.sYI/src/tests/ called runtests.log.20240612-1935.1678 which keeps on growing until I kill the test (currently at 27 GB), it ends with seemingly endless repeats of: regression-test: 301 tests passed regression-test: 0 tests failed error: quit already called with exit code 0 I'll file a bug report with puredata shortly as a pure testing run is still fine. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073078: puredata breaks pd-iemmatrix autopkgtest: it now times out
Source: puredata, pd-iemmatrix Control: found -1 puredata/0.55.0+ds-1 Control: found -1 pd-iemmatrix/0.4.0-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of puredata the autopkgtest of pd-iemmatrix fails in testing when that autopkgtest is run with the binary packages of puredata from unstable. What's worse, where the test normally passes within 10s of seconds to 2 minutes, it now times out after 2:47 hours. It passes when run with only packages from testing. In tabular form: passfail puredata from testing0.55.0+ds-1 pd-iemmatrix from testing0.4.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Unfortunately there's isn't much to see. Currently this regression is blocking the migration of puredata to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=puredata https://ci.debian.net/data/autopkgtest/testing/amd64/p/pd-iemmatrix/47558213/log.gz 46s /usr/bin/pd 10043s autopkgtest [07:14:01]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; exec /tmp/autopkgtest-lxc.scjcgjj4/downtmp/wrapper.sh --artifacts=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/run-suite-sysinstalled-artifacts --chdir=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/build.pM8/src --env=DEB_BUILD_OPTIONS=parallel=64 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/run-suite-sysinstalled-stderr --stdout=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/run-suite-sysinstalled-stdout --tmp=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/autopkgtest_tmp --make-executable=/tmp/autopkgtest-lxc.scjcgjj4/downtmp/build.pM8/src/debian/tests/run-suite-sysinstalled -- /tmp/autopkgtest-lxc.scjcgjj4/downtmp/build.pM8/src/debian/tests/run-suite-sysinstalled" (kind: test) 10043s autopkgtest [07:14:01]: test run-suite-sysinstalled OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079808: sonic-pi: autopkgtest regression: times out
Source: sonic-pi Version: 3.2.2~repack-9 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it fails since July 2024. What's worse, it seems to hang and times out after 2:47 hours while normally it ran only several minutes. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/packages/s/sonic-pi/unstable/arm64/51053425/ 237s Attribute Qt::AA_EnableHighDpiScaling must be set before QCoreApplication is created. 237s ╘ 237s ─ ╛▒╛ 237s ▐╫ ▄█├ 237s─╟╛ █▄ ╪▓▀ 237s ╓┤ ╩▌ ██ ▀▓▌ 237s ▐▒ ╬▒ ╟▓╘─▓█ ▓▓├ 237s ▒╫ ▒╪ ▓█ ▓▓─ ▓▓▄ 237s ╒▒─ │▒ ▓█ ▓▓ ─▓▓─ 237s ╬▒ ▄▒ ╒╪▓═╬▓╬ ▌▓▄ 237s ╥╒ ╦╥ ╕█╒╙▓▐ ▄▓╫ 237s ▐╩ ▒▒ ▀▀ 237s ╒╪ ▐▄ 237s 237s_ __ __ 237s / ___/ /_/ / __ \/_/ 237s \__ \/ __ \/ __ \/ / ___/ / /_/ / / 237s ___/ / /_/ / / / / / /__ / / / 237s //\/_/ /_/_/\___/ /_/ /_/ 237s 237sThe Live Coding Music Synth for Everyone 237s 237s http://sonic-pi.net 237s 237s [GUI] - reading settings 1031s JackTimedDriver::Process XRun = 30 usec 1534s JackTimedDriver::Process XRun = 31 usec 10177s autopkgtest [13:14:38]: ERROR: timed out OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1023220: src:pd-flext: fails to migrate to testing for too long: autopkgtest failure on armel and armhf
Source: pd-flext Version: 0.6.1-3 Severity: serious Control: close -1 0.6.2-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:pd-flext has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package recently gained an autopkgtest (great), however it fails on armel and armhf: fatal error: gnu/stubs-hard.h: No such file or directory If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=pd-flext OpenPGP_signature Description: OpenPGP digital signature
Bug#1023398: src:ardour: unsatisfied build dependency in testing: python3-rdflib
Source: ardour Version: 1:6.9.0+ds0-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1012482 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature Description: OpenPGP digital signature
Bug#1024162: src:csound-plugins: unsatisfied build dependency in testing: libgmm++-dev
Source: csound-plugins Version: 1.0.2~dfsg1-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: edos-uninstallable Control: block -1 by 1023788 Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. In this case, src:getfem took over from src:getfem++ but it is blocked because if fails to build from source on s390x, see bug #1023788. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature Description: OpenPGP digital signature
Bug#1024169: csound breaks csound-plugins autopkgtest: *** stack smashing detected ***: terminated
Source: csound, csound-plugins Control: found -1 csound/1:6.18.0+dfsg-2 Control: found -1 csound-plugins/1.0.2~dfsg1-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of csound the autopkgtest of csound-plugins fails in testing when that autopkgtest is run with the binary packages of csound from unstable. It passes when run with only packages from testing. In tabular form: passfail csound from testing1:6.18.0+dfsg-2 csound-plugins from testing1.0.2~dfsg1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of csound to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=csound https://ci.debian.net/data/autopkgtest/testing/arm64/c/csound-plugins/28320936/log.gz *** stack smashing detected ***: terminated csound command: Aborted csound command: Segmentation fault autopkgtest [17:15:52]: test command1 OpenPGP_signature Description: OpenPGP digital signature
Bug#1036881: whitedune: segfaults
Package: whitedune Version: 0.30.10-2.2 Severity: serious Justification: segfaults Hi, I just tried to run whitedune, but it segfaults. paul@mulciber ~ $ whitedune Segmentation fault (core dumped) paul@mulciber ~ $ whitedune --version white_dune whitedune-0.30.10 paul@mulciber ~ $ whitedune --help Segmentation fault (core dumped) Paul -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages whitedune depends on: ii libc6 2.36-9 ii libexpat1 2.5.0-1 ii libgcc-s1 [libgcc1] 12.2.0-14 ii libgl1 1.6.0-1 ii libglu1-mesa [libglu1] 9.0.2-1.1 ii libjpeg62-turbo 1:2.1.5-2 ii libpng16-16 1.6.39-2 ii libstdc++6 12.2.0-14 ii libx11-62:1.8.4-2 ii libxi6 2:1.8-1+b1 ii libxm4 2.3.8-3 ii libxmu6 2:1.1.3-3 ii libxt6 1:1.2.1-1.1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages whitedune recommends: ii xfonts-100dpi 1:1.0.5 ii xfonts-75dpi 1:1.0.5 Versions of packages whitedune suggests: pn whitedune-docs pn x-www-browser -- no debconf information
Bug#1036881: whitedune: segfaults
tags 1036881 bookworm-ignore user release.debian@packages.debian.org usertag 1036881 bookworm-can-defer thanks Hi, On 28-05-2023 20:17, Andrey Rakhmatullin wrote: whitedune 0.30.10 was uploaded to Debian in 2011, the current version (the new homepage is https://wdune.ourproject.org/) is 1.956, released, I assume, in 2020, and its SFNode::SFNode() doesn't do this anymore. I don't see a VCS so I can't find a change that did this. For the avoidance of doubt, it's too late in the freeze to actually fix this issue and because there are reverse (build) dependencies involved which still work without whitedune functioning, I'll not remove the package, hence the tags. I'll try to remember to remove the bookworm-ignore tag after the release. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1038126: src:python-pyo: fails to migrate to testing for too long: FTBFS on i386
Source: python-pyo Version: 1.0.4-1 Severity: serious Control: close -1 1.0.5-2 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:python-pyo has been trying to migrate for 80 days [2]. Hence, I am filing this bug. Your package failed to build from source on i386, while it built there successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=python-pyo OpenPGP_signature Description: OpenPGP digital signature
Bug#1041218: src:ardour: fails to migrate to testing for too long: FTBFS on mips*el
Source: ardour Version: 1:7.3.0+ds0-1 Severity: serious Control: close -1 1:7.4.0+ds-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:ardour has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The package in unstable fails to build on mips64el and mipsel, while it built there successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=ardour OpenPGP_signature Description: OpenPGP digital signature
Bug#1050060: src:pd-iemmatrix: fails to migrate to testing for too long: autopkgtest regression on i386
Source: pd-iemmatrix Version: 0.3.2-4 Severity: serious Control: close -1 0.3.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pd-iemmatrix has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails it's own autopkgtest on i386. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pd-iemmatrix OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050614: src:dpf-plugins: fails to migrate to testing for too long: uploader built arch:all binaries
Source: dpf-plugins Version: 1.6+ds-2 Severity: serious Control: close -1 1.7+ds-1 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:dpf-plugins has been trying to migrate for 31 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=dpf-plugins OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050828: src:pd-xsample: fails to migrate to testing for too long: FTBFS on ppc64el
Source: pd-xsample Version: 0.3.2+git20170905.1.4441ae5-5 Severity: serious Control: close -1 0.3.2+git20170905.1.4441ae5-6 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pd-xsample has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on ppc64el, while it built there successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pd-xsample OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061723: src:obs-studio: fails to migrate to testing for too long: FTBFS on ppc64el
Source: obs-studio Version: 29.1.3+dfsg-2 Severity: serious Control: close -1 30.0.2+dfsg-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1061420 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:obs-studio has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on ppc64el as reported in bug 1061420. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=obs-studio OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063075: src:olive-editor: fails to migrate to testing for too long: FTBFS
Source: olive-editor Version: 20221024+ds-1 Severity: serious Control: close -1 20230614+ds-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1060206 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:olive-editor has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build as reported in bug 1060206. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=olive-editor OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1005395: src:gem: fails to migrate to testing for too long: FTBFS on ppc64el
Source: gem Version: 1:0.94-3 Severity: serious Control: close -1 1:0.94-5 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:gem has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package fails to build from source on ppc64el while it built there in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gem OpenPGP_signature Description: OpenPGP digital signature
Bug#1005912: hydrogen: autopkgtest regression on arm64 and ppc64el: H2Core::Instrument::dequeue(): Assertion `__queued > 0' failed.
Source: hydrogen Version: 1.1.1-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of hydrogen the autopkgtest of hydrogen fails in testing when that autopkgtest is run with the binary packages of hydrogen from unstable on arm64 and ppc64el. It passes when run with only packages from testing. In tabular form: passfail hydrogen from testing1.1.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. I note that on amd64 the test also failed for a couple of days due to a segfault before it passed yesterday. I suspect you're missing a *versioned* dependency which migrated to testing apparently somewhere yesterday. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=hydrogen https://ci.debian.net/data/autopkgtest/testing/arm64/h/hydrogen/19286560/log.gz Generate test.wav from GM_kit_Jazzy.h2song with a bit depth of 24 and a sampling rate of 96000 Hz Hydrogen 1.1.1- [Feb 8 2022] [http://www.hydrogen-music.org] Copyright 2002-2008 Alessandro Cominu Copyright 2008-2021 The hydrogen development team Hydrogen comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details Error: can't open log file for writing... Cannot connect to server socket err = No such file or directory Cannot connect to server request channel exec of JACK server (command = "/usr/bin/jackd") failed: No such file or directory Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock Cannot connect to server socket err = No such file or directory Cannot connect to server request channel exec of JACK server (command = "/usr/bin/jackd") failed: No such file or directory Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock ALSA lib seq_hw.c:466:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for 0 ALSA lib confmisc.c:855:(parse_card) cannot find card '0' ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_card_inum returned error: No such file or directory ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM default Cannot connect to server socket err = No such file or directory Cannot connect to server request channel exec of JACK server (command = "/usr/bin/jackd") failed: No such file or directory Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory Cannot connect to server request channel Cannot connect to server socket err = No such file or directory
Bug#1005912: hydrogen: autopkgtest regression on arm64 and ppc64el: H2Core::Instrument::dequeue(): Assertion `__queued > 0' failed.
Hi Nicholas, Thanks for reaching out. On 24-02-2022 06:13, Nicholas D Steeves wrote: Paul and Debian CI team, do you know if a dummy alsa driver (and dummy sequencer driver) can be enabled on DebCI systems? You are in control of your testbed, can't you do this in your test? Or can you only do this in isolation-machine testbeds (not sure how this driver thing works)? And why would only arm64 need it? This would make the testbed more comparable to a real system and increase the value of the tests for multimedia packages. If not, please feel free to skip to the bottom of this email. To be honest, I don't really like tweaking the hosts, as other autopkgtest instances outside our control would need to learn to do this too. When I run autopkgtests locally they now error due to missing audio hardware where previously they passed, and this wasn't the case when the package was uploaded. The test on ppc64el now passed after several failure due to segmentation faults. Not sure if this is now a highly flaky test, or just that the issue has been fixed in the mean time on ppc64el It looks to me like "allow-stderr" is no longer sufficient to allow the export-to-wav functional test to pass, eg: (E) JackAudioDriver::init Unknown status with JACK server. (E) ::H2Core::AudioOutput* H2Core::createDriver(const QString&) Error starting audio driver [audioDriver::init()] (E) AlsaAudioDriver::connect ALSA: cannot open audio device hw:0:No such file or directory (E) AlsaAudioDriver::connect ALSA: cannot open audio device default:No such file or directory (E) ::void H2Core::audioEngine_startAudioDrivers() Error starting audio driver [audioDriver::connect()] (E) ::void H2Core::audioEngine_startAudioDrivers() Using the NULL output audio driver (E) ::void* H2Core::alsaMidiDriver_thread(void*) Error opening ALSA sequencer: No such file or directory But this text is also there on passing tests. So either that's no problem, or the test doesn't fail while it should. The available solutions appear to be 1) Enable a dummy sound card. 2) Ask upstream to support running utility functions such as this wav file export without attempting to bind to hardware. 3) Remove the autopkgtest. 4) Something else. Again, why only arm64? My first instinct is to choose option #3, because it doesn't depend on other people; however, obviously we all value CI and want to work towards enhancing its value rather than removing tests. So that leaves options #1, #2, and #4 (yet undefined). I guess there's always "foo || true", but I hope everyone reading this will agree that that is bad style that reduces the value of CI. I would prefer option #1, because it increases the real-world value of these tests, and because I don't know how to justify #2 to upstream. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1006623: src:lsp-plugins: fails to migrate to testing for too long: FTBFS on armhf
Source: lsp-plugins Version: 1.1.30-1 Severity: serious Control: close -1 1.1.31-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1003904 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:lsp-plugins has been trying to migrate for 62 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=lsp-plugins OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1005912: hydrogen: autopkgtest regression on arm64 and ppc64el: H2Core::Instrument::dequeue(): Assertion `__queued > 0' failed.
Hi Nicholas On 02-04-2022 00:13, Nicholas D Steeves wrote: On 24-02-2022 06:13, Nicholas D Steeves wrote: Paul and Debian CI team, do you know if a dummy alsa driver (and dummy sequencer driver) can be enabled on DebCI systems? You are in control of your testbed, can't you do this in your test? Or can you only do this in isolation-machine testbeds (not sure how this driver thing works)? I was thinking that this would require a `modprobe snd-dummy`, and I'm assuming loading arbitrary kernel modules is blocked on DebCI systems. We don't "block" anything. But on ci.d.n things need to work in lxc for now. Again, I'm not into the details, but I think indeed that you need isolation-machine for that. It's been a few months since I contacted the CI Team about isolation-machines, but they're not yet ready for use either. That's still correct, and I don't expect that to change in the short term. We're more focused on adding other architectures to enable the Release Team to test all release architectures and maintaining the infrastructure as-is. That's already more work that I'd expected upfront. My request for snd-dummy on DebCI isn't arm64 specific; I noticed that jackd2 doesn't have autopkgtest enabled, and hypothesised that missing audio hardware was the reason why. Jackd2 maintainers are now in CC because would know better than I :-) I see a lot of flaky tests with jack mentioned in the error (failure to start or something). Maybe that's remotely related? To be honest, I don't really like tweaking the hosts, as other autopkgtest instances outside our control would need to learn to do this too. I completely understand, and the only way this request would be justifiable is if it provided a meaningful boost in quality assurance for audio-related packages. I'm wondering if this warrants a new autopkgtest restrictions (probably not): isolation-machine-or-needs-${group-of-defined-kernel-modules}. I have the feeling that could become a big list for all kind of use cases. When I run autopkgtests locally they now error due to missing audio hardware where previously they passed, and this wasn't the case when the package was uploaded. The test on ppc64el now passed after several failure due to segmentation faults. Not sure if this is now a highly flaky test, or just that the issue has been fixed in the mean time on ppc64el When I contacted upstream, I learned that the cause may be that the CLI utilities are poorly maintained. Is this sufficient justification for disabling the autopkgtests ie: that it's due diligence and not laziness? Well, if a test is truly flaky for whatever reason, ci.d.n and the Release Team agree that the test should either not be run or marked as flaky. The latter only has value if some human still regularly checks. The same goes for failure on a particular architecture. If you believe the failure is due to CI and not because the package itself is wrong, then just don't test there (Architecture field in d/t/control). If the package is broken and can't reasonably be fixed, have it removed from that architecture (in unstable; ftp.debian.org pseudo package) and don't build on that architecture anymore. In that case CI found out that the package is broken and that's a good thing. Thank you again for having this conversation. I want to support our CI team and technical excellence rather than just "unblock migration to testing", but will of course defer to your recommendations. Sometimes you need to (for the time being) take a practical stance. I'm not saying yet that we'll not enable the snd-dummy module (I hope for follow-up), but in the present case, if the test can't reliably run on the present infrastructure, and nobody is promising a solution on the short term, you should not make your own live too hard and you should not run the tests for now. Or prepare for the isolation-machine situation (I think Ubuntu has that on most architectures) and hope it will arrive someday in Debian too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1009272: src:hydrogen: fails to migrate to testing for too long: unresolved RC bug (flaky autopkgtest)
Source: hydrogen Version: 1.0.1-3 Severity: serious Control: close -1 1.1.1-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1005912 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:hydrogen has been trying to migrate for 61 days [2]. Hence, I am filing this bug. I recognize I've been in contact with you on the blocking bug report, but it's time to determine how to move on (even if it were not the final solution). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=hydrogen OpenPGP_signature Description: OpenPGP digital signature
Bug#1010484: src:libigloo: fails to migrate to testing for too long: FTBFS on s390x
Source: libigloo Version: 0.9.0-1 Severity: serious Control: close -1 0.9.1-1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:libigloo has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build from source on s390x while it built successfully there in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=libigloo OpenPGP_signature Description: OpenPGP digital signature
Bug#1012189: src:intel-media-driver: fails to migrate to testing for too long: unresolved RC bug
Source: intel-media-driver Version: 22.2.1+dfsg1-1 Severity: serious Control: close -1 22.4.2+dfsg1-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1008776 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:intel-media-driver has been trying to migrate for 61 days [2]. Hence, I am filing this bug. The migration of your package is blocked by an unresolved RC bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=intel-media-driver OpenPGP_signature Description: OpenPGP digital signature
Bug#1014422: src:zynaddsubfx: fails to migrate to testing for too long: ftbfs on arm64, ppc64el and s390x
Source: zynaddsubfx Version: 3.0.5-2 Severity: serious Control: close -1 3.0.6-1 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:zynaddsubfx has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package failed to build from source on arm64, ppc64el and s390x while it built there successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=zynaddsubfx OpenPGP_signature Description: OpenPGP digital signature
Bug#1014643: Depends on mplayer which isn't in testing
Package: dradio Version: 3.8-2 Tags: sid bookworm Severity: serious Control: clone -1 -2 -3 -4 Control: reassign -2 qwinff 0.2.1+git20201215-1 Control: reassign -3 vdr-plugin-mp3 0.10.4-2 Control: reassign -4 videotrans 1.6.1-8 Dear maintainer, Your package Depends on mplayer, which currently isn't in testing and has severe issue so is unlikely to migrate soon. Your package was removed from testing because of RC bugs in mplayer, but somehow (probably a race condition) migrated back to testing. This bug is meant to autoremove your package, as currently it can't be installed in a testing environment. You can close the bug once your package has been removed from testing. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1015932: src:inkscape: fails to migrate to testing for too long: ftbfs on arm64, ppc64el, s390x
Source: inkscape Version: 1.1.2-3 Severity: serious Control: close -1 1.2.1+ds-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1012496 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:inkscape has been trying to migrate for 62 days [2]. Hence, I am filing this bug. Your package fails to build from source as reported in bug #1012496. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=inkscape OpenPGP_signature Description: OpenPGP digital signature
Bug#1016444: snd: build depends on libnotcurses-dev not available in bookworm
Source: snd Version: 22.3-1 Severity: serious Control: block -1 by 1001661 Dear maintainer, libnotcurses-dev hasn't been in bookworm/testing for nearly three months. Your package build depends on it, so your package can't be rebuild in bookworm. It's also blocking the migration of the version in unstable. As you noted in the notcurses bug, your package seems buildable without the dependency so I think for now that's the best way forward. I didn't want to downgrade 1001661 because the latest version had three timeouts in March, so the issue doesn't seem solved yet. To confirm I triggered 10 new runs and 1 of them timed out. The ratio just isn't good enough. Paul
Bug#1016939: : flaky autopkgtest: padthv1_jack: no process found
Source: padthv1 Version: 0.9.17-1 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of you package because it was showing up as a regression for the upload of glibc. I noticed that the test regularly fails on ppc64el [1]. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [1] https://ci.debian.net/packages/p/padthv1/testing/ppc64el/ E.g. https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/padthv1/24099886/log.gz autopkgtest [18:54:41]: test simpletest: [--- Simple test success! We kill padthv1_jack because it doesn’t close itself in the testbed padthv1_jack: no process found autopkgtest [18:54:42]: test simpletest: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#1019390: o2: autopkgtest regression on i386 and s390x: Assertion `arg->v.vf[i] == 123.456F + i' failed.
Source: o2 Version: 1.1~ds-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of o2 the autopkgtest of o2 fails in testing on i386 and s390x when that autopkgtest is run with the binary packages of o2 from unstable. It passes when run with only packages from testing. In tabular form: passfail o2 from testing1.1~ds-1 all others from testingfrom testing I copied some of the output on i386 at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=o2 https://ci.debian.net/data/autopkgtest/testing/i386/o/o2/24929151/log.gz make: Entering directory '/tmp/autopkgtest-lxc.xo3rn8r3/downtmp/build.74d/src/debian/tests' ./arraytest DONE sending [3456] DONE sending [] DONE sending [123, 234] DONE sending [xixdx] messages DONE sending 456,[456,12345][1234.56,1234.567,2345.678],1234.567 arraytest: ../../test/arraytest.c:502: service_ifvxif: Assertion `arg->v.vf[i] == 123.456F + i' failed. make: *** [Makefile:64: arraytest.test] Aborted make: Leaving directory '/tmp/autopkgtest-lxc.xo3rn8r3/downtmp/build.74d/src/debian/tests' autopkgtest [19:16:11]: test simple_run OpenPGP_signature Description: OpenPGP digital signature
Bug#1085189: src:libdrumstick: fails to migrate to testing for too long
Source: libdrumstick Version: 2.9.0-1.1 Severity: serious Control: close -1 2.9.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:libdrumstick has been trying to migrate for 32 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=libdrumstick Current text from [2]: Migration status for libdrumstick (2.9.0-1.1 to 2.9.1-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ Updating libdrumstick would introduce bugs in testing: #1081716 ∙ ∙ missing build on arm64 ∙ ∙ arch:arm64 not built yet, autopkgtest delayed there Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/libd/libdrumstick.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Waiting for reproducibility test results on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 32 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1085887: src:easyeffects: fails to migrate to testing for too long
Source: easyeffects Version: 7.1.7-1 Severity: serious Control: close -1 7.1.9-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:easyeffects has been trying to migrate for 31 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=easyeffects Current text from [2]: Migration status for easyeffects (7.1.7-1 to 7.1.9-1): BLOCKED: Maybe temporary, maybe blocked but Britney is missing information (check below) Issues preventing migration: ∙ ∙ missing build on armel ∙ ∙ arch:armel not built yet, autopkgtest delayed there Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/e/easyeffects.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Reproducible on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 31 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1086457: src:faust: fails to migrate to testing for too long
Source: faust Version: 2.74.6+ds-1 Severity: serious Control: close -1 2.75.7+ds-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:faust has been trying to migrate for 32 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=faust Current text from [2]: Migration status for faust (2.74.6+ds-1 to 2.75.7+ds-2): BLOCKED: Maybe temporary, maybe blocked but Britney is missing information (check below) Issues preventing migration: ∙ ∙ missing build on armel ∙ ∙ missing build on i386 ∙ ∙ arch:armel not built yet, autopkgtest delayed there ∙ ∙ arch:i386 not built yet, autopkgtest delayed there Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/f/faust.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Reproducible on armhf - info ♻ ∙ ∙ 20 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1082186: src:sonic-visualiser: fails to migrate to testing for too long
Source: sonic-visualiser Version: 4.5.2-2 Severity: serious Control: close -1 5.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:sonic-visualiser has been trying to migrate for 31 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=sonic-visualiser Current text from [2]: Migration status for sonic-visualiser (4.5.2-2 to 5.0-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ Updating sonic-visualiser would introduce bugs in testing: #1080495 ∙ ∙ sonic-visualiser unsatisfiable Build-Depends(-Arch) on armel: qt6-pdf-dev ∙ ∙ sonic-visualiser unsatisfiable Build-Depends(-Arch) on mips64el: qt6-pdf-dev ∙ ∙ sonic-visualiser unsatisfiable Build-Depends(-Arch) on ppc64el: qt6-pdf-dev ∙ ∙ sonic-visualiser unsatisfiable Build-Depends(-Arch) on riscv64: qt6-pdf-dev ∙ ∙ sonic-visualiser unsatisfiable Build-Depends(-Arch) on s390x: qt6-pdf-dev ∙ ∙ missing build on armel ∙ ∙ missing build on mips64el ∙ ∙ missing build on ppc64el ∙ ∙ missing build on riscv64 ∙ ∙ missing build on s390x ∙ ∙ arch:armel not built yet, autopkgtest delayed there ∙ ∙ arch:ppc64el not built yet, autopkgtest delayed there ∙ ∙ arch:riscv64 not built yet, autopkgtest delayed there ∙ ∙ arch:s390x not built yet, autopkgtest delayed there Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/s/sonic-visualiser.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Waiting for reproducibility test results on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 31 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1083056: src:shotcut: fails to migrate to testing for too long
Source: shotcut Version: 24.06.26+git20240816+ds-1 Severity: serious Control: close -1 24.09.13+ds-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:shotcut has been trying to migrate for 31 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=shotcut Current text from [2]: Migration status for shotcut (24.06.26+git20240816+ds-1 to 24.09.13+ds-1): BLOCKED: Maybe temporary, maybe blocked but Britney is missing information (check below) Issues preventing migration: ∙ ∙ missing build on armel ∙ ∙ missing build on armhf ∙ ∙ missing build on i386 ∙ ∙ arch:armel not built yet, autopkgtest delayed there ∙ ∙ arch:armhf not built yet, autopkgtest delayed there ∙ ∙ arch:i386 not built yet, autopkgtest delayed there Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/s/shotcut.html ∙ ∙ Ignoring non-reproducibility on amd64 (not a regression) - info ♻ ∙ ∙ Ignoring non-reproducibility on arm64 (not a regression) - info ♻ ∙ ∙ Waiting for reproducibility test results on armhf - info ♻ ∙ ∙ 11 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1090932: dh-puredata: autopkgtest fails with debhelper 13.22
Control: severity -1 serious On Fri, 20 Dec 2024 14:35:00 -0700 Zixing Liu wrote: This fixes the compatibility issues with debhelper 13.22+. Which is currently blocking the migration of debhelper to testing. These bugs are severity serious. As dh-buildinfo was removed a bit too quick from testing, there's now a huge amount of FTBFS bugs in testing without debhelper migrating. I'm going to hint it through, but then dh-puredata will have a failing autopkgtest in testing. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1089847: src:gsequencer: fails to migrate to testing for too long
Source: gsequencer Version: 6.16.23-1 Severity: serious Control: close -1 7.2.4-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gsequencer has been trying to migrate for 31 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gsequencer Current text from [2]: Migration status for gsequencer (6.16.23-1 to 7.2.4-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ gir1.2-ags-7.0/armel has unsatisfiable dependency ∙ ∙ gir1.2-agsaudio-7.0/armel has unsatisfiable dependency ∙ ∙ gir1.2-agsgui-7.0/armel has unsatisfiable dependency ∙ ∙ gsequencer/armel has unsatisfiable dependency ∙ ∙ libags-audio7t64/armel has unsatisfiable dependency ∙ ∙ libags7t64/armel has unsatisfiable dependency ∙ ∙ gir1.2-ags-7.0/armhf has unsatisfiable dependency ∙ ∙ gir1.2-agsaudio-7.0/armhf has unsatisfiable dependency ∙ ∙ gir1.2-agsgui-7.0/armhf has unsatisfiable dependency ∙ ∙ gsequencer/armhf has unsatisfiable dependency ∙ ∙ libags-audio7t64/armhf has unsatisfiable dependency ∙ ∙ libags7t64/armhf has unsatisfiable dependency ∙ ∙ autopkgtest for gsequencer/7.2.4-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Pass Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/g/gsequencer.html ∙ ∙ uninstallable on arch armel, not running autopkgtest there ∙ ∙ uninstallable on arch armhf, not running autopkgtest there ∙ ∙ Ignoring non-reproducibility on amd64 (not a regression) - info ♻ ∙ ∙ Ignoring non-reproducibility on arm64 (not a regression) - info ♻ ∙ ∙ Ignoring non-reproducibility on armhf (not a regression) - info ♻ ∙ ∙ Ignoring non-reproducibility on i386 (not a regression) - info ♻ ∙ ∙ 31 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1090944: src:juce: fails to migrate to testing for too long
Source: juce Version: 8.0.3+ds-2 Severity: serious Control: close -1 8.0.4+ds-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:juce has been trying to migrate for 31 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=juce Current text from [2]: Migration status for juce (8.0.3+ds-2 to 8.0.4+ds-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ autopkgtest for juce/8.0.4+ds-1: amd64: Pass, arm64: Pass, armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: No tests, superficial or marked flaky ♻ (reference ♻) Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/j/juce.html ∙ ∙ Reproducibility regression on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Reproducibility regression on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 31 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1090932: dh-puredata: autopkgtest fails with debhelper 13.22
Control: notfound -1 3.2.0 Hi, On Mon, 20 Jan 2025 12:50:05 +0100 IOhannes m zmoelnig wrote: since debhelper/13.24 has fixed the underlying issue ('install' not returning an exit code) and therefore the dh-puredata autopktests are successful again, i'm going to close this. Sure, but the bts logic concludes this bug still affects testing because of the "found" version, so I'm removing that. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1094135: csound: flaky autopkgtest on s390x: Csound tidy up: Illegal instruction
Source: csound Version: 1:6.18.1+dfsg-3 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package because it showed up on the excuses list of glibc. I noticed that it regularly fails on s390x. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul https://ci.debian.net/packages/c/csound/testing/s390x/55147865/ 185s autopkgtest [02:36:24]: test command4: [--- 186s UnifiedCSD: tests/commandline/test1.csd 186s Elapsed time at end of orchestra compile: real: 0.001s, CPU: 0.001s 186s [msorting score ... 186s... done 186s Elapsed time at end of score sort: real: 0.003s, CPU: 0.001s 186s [m--Csound version 6.18 (double samples) 2024-08-21 186s [commit: none] 186s [mlibsndfile-1.2.2 186s [mgraphics suppressed, ascii substituted 186s sr = 44100.0,[m kr = 44100.000,[m ksmps = 1 186s [m0dBFS level = 32768.0,[m A4 tuning = 440.0 186s [morch now loaded 186s [maudio buffered in 256 sample-frame blocks 186s [mwriting 512-byte blks of shorts to test.wav (WAV) 186s SECTION 1: 186s [mnew alloc for instr 1: 186s [mB 0.000 .. 2.000 T 2.000 TT 2.000 M: 11564.5 186s Score finished in csoundPerform(). 186s Csound tidy up: Illegal instruction 186s inactive allocs returned to freespace 186s end of score. overall amps:[m 11564.5 186s overall samples out of range:[m0[m 186s 0 errors in performance 186s [mElapsed time at end of performance: real: 0.278s, CPU: 0.015s 186s [m256 512 sample blks of shorts written to test.wav (WAV) 186s backtrace() returned 3 addresses 186s /lib/s390x-linux-gnu/libcsound64.so.6.0(+0x4c6de) [0x3ff76b4c6de] 186s linux-vdso64.so.1(__kernel_sigreturn+0) [0x3ffec398498] 186s [0x3ff94924f26] 187s autopkgtest [02:36:26]: test command4: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1102592: src:lsp-plugins: fails to migrate to testing for too long
Source: lsp-plugins Version: 1.2.16-1 Severity: serious Control: close -1 1.2.21-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:lsp-plugins has been trying to migrate for 32 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=lsp-plugins Current text from [2]: Migration status for lsp-plugins (1.2.16-1 to 1.2.21-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ autopkgtest for lsp-plugins/1.2.21-1: amd64: Regression or new test ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ (reference ♻), riscv64: Regression or new test ♻ (reference ♻), s390x: Regression or new test ♻ (reference ♻) ∙ ∙ missing build on armel ∙ ∙ missing build on i386 ∙ ∙ arch:armel not built yet, autopkgtest delayed there ∙ ∙ arch:i386 not built yet, autopkgtest delayed there Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/l/lsp-plugins.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Waiting for reproducibility test results on armhf - info ♻ ∙ ∙ 31 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1095992: src:pysoundfile: fails to migrate to testing for too long
Source: pysoundfile Version: 0.12.1-1 Severity: serious Control: close -1 0.13.1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pysoundfile has been trying to migrate for 34 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. It seems to me like you tried in your last upload to testing on s390x. Did you know that the autopkgtest has a spec for "Architecture" and that you can negate it? The test you don't want to run on s390x could be declared as Architecture: !s390x and it would be skipped on s390x. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pysoundfile Current text from [2]: Migration status for pysoundfile (0.12.1-1 to 0.13.1-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ autopkgtest for pysoundfile/0.13.1-1: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Regression or new test ♻ (reference ♻) ∙ ∙ Too young, only 4 of 5 days old Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/p/pysoundfile.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Reproducible on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1108758: sonic-pi: autopkgtest depends on jack-capture which isn't in testing
Source: sonic-pi Version: 3.2.2~repack-11 Severity: serious User: debian...@lists.debian.org Usertags: regression Tags: trixie-ignore Dear maintainer(s), Your package has an autopkgtest, great. However, it fails because it depends on jack-capture, which isn't in testing due to a long standing RC bug. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation With my Release Team member hat on I have tagged this as trixie-ignore as it's so late in the freeze and it's not worth removing the package from trixie because of this at this moment. Having said that, if a fix is possible without fully removing the autopkgtest and without making the test superficial, it's still welcome, but it would need to happen soon. Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1110263: openshot-qt: does not start at all -- AttributeError: type object 'GreenSocket' has no attribute 'sendmsg'
Hi Alexandre, On Sat, 02 Aug 2025 13:41:15 +0200 Alexandre Detiste wrote: I tried openshot-qt today and it does not start at all. Just a data point, it works for me on my trixie system. Paul paul@toba ~ $ sudo apt install openshot-qt Installing: openshot-qt Installing dependencies: fonts-cantarell libjsoncpp26 libopenshot-audio9t64 python3-openshot libjs-angularjs libmagick++-7.q16-5 libopenshot25t64 Suggested packages: blender inkscape openshot-qt-doc Summary: Upgrading: 0, Installing: 8, Removing: 0, Not Upgrading: 0 Download size: 80.8 MB Space needed: 158 MB / 113 GB available Continue? [Y/n] [...] Get:8 http://deb.debian.org/debian trixie/main amd64 openshot-qt all 3.1.1+dfsg1-3 [78.0 MB] [...] Setting up openshot-qt (3.1.1+dfsg1-3) ... /usr/lib/python3/dist-packages/openshot_qt/language/generate_translations.py:25: SyntaxWarning: invalid escape sequence '\;' $ find -iname "*.po" -exec msgfmt {} -o {}.mo \; /usr/lib/python3/dist-packages/openshot_qt/language/generate_translations.py:106: SyntaxWarning: invalid escape sequence '\;' subprocess.call('find %s -iname "*.py" -exec xgettext -j -o %s --keyword=_ {} \;' % ( [...] paul@toba ~ $ openshot-qt 2> /dev/null Loaded modules from: /usr/lib/python3/dist-packages/openshot_qt Screen eDP-1 devicePixelRatio: 2.0 logicalDotsPerInch: 96.0 physicalDotsPerInch: 126.19216605289589 availableSizes: PyQt5.QtCore.QSize(1536, 864) paul@toba ~ $ echo $? 0 OpenPGP_signature.asc Description: OpenPGP digital signature