RFS winff - GUI video and audio batch converter using ffmpeg

2008-08-29 Thread Paul Gevers
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.

2019-10-31 Thread Paul Gevers
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

2019-11-02 Thread Paul Gevers
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

2019-12-12 Thread Paul Gevers
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

2019-12-17 Thread Paul Gevers
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

2019-12-17 Thread Paul Gevers
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

2019-12-29 Thread Paul Gevers
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

2020-02-06 Thread Paul Gevers
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

2020-02-06 Thread Paul Gevers
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

2020-02-06 Thread Paul Gevers
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

2020-03-12 Thread Paul Gevers
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

2020-03-29 Thread Paul Gevers
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

2020-04-21 Thread Paul Gevers
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

2020-05-09 Thread Paul Gevers
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

2020-06-19 Thread Paul Gevers
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

2020-12-21 Thread Paul Gevers
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

2020-12-22 Thread Paul Gevers
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

2021-01-04 Thread Paul Gevers
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

2021-01-08 Thread Paul Gevers
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

Buffer: 4.03s./4.03sTime: 0.09m.   DHP: [ ]  Overruns: 0
Xruns: 0
00:|
  |
01:| |
Buffer: 4.03s./4.03sTime: 0.09m.   DHP: [ ]  Overruns: 0
Xruns: 0
00:|
  |
01:| |
Buffer: 4.03s./4.03sTime: 0.09m.   DHP: [ ]  Overruns: 0
Xruns: 0


>>> Please wait while writing all data to disk. (shouldn't take long)
   |"|
00:|
  |
01:| |
Buffer: 4.05s./4.05sTime: 0.10m.   DHP: [ ]  Overruns: 0
Xruns: 0
00:|
  |
01:| |
Buffer: 4.05s./4.05sTime: 0.10m.   DHP: [ ]  Overruns: 0
Xruns: 0
Finished.
unknown bpm
autopkgtest [17:56:12]: test gui: ---]



OpenPGP_signature
Description: OpenPGP digital signature


Bug#953289: ABI change in libsoxr 0.1.3

2021-01-15 Thread Paul Gevers
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

2010-11-15 Thread Paul Gevers
> 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

2021-02-04 Thread Paul Gevers
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.

2021-02-05 Thread Paul Gevers
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

2021-11-27 Thread Paul Gevers

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)

2021-11-28 Thread Paul Gevers

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'

2021-12-09 Thread Paul Gevers

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

2024-06-12 Thread Paul Gevers

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

2024-06-12 Thread Paul Gevers

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

2024-08-27 Thread Paul Gevers

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

2022-10-31 Thread Paul Gevers

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

2022-11-03 Thread Paul Gevers

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

2022-11-15 Thread Paul Gevers

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

2022-11-15 Thread Paul Gevers

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

2023-05-28 Thread Paul Gevers
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

2023-05-28 Thread Paul Gevers

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

2023-06-15 Thread Paul Gevers

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

2023-07-15 Thread Paul Gevers

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

2023-08-18 Thread Paul Gevers

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

2023-08-26 Thread Paul Gevers

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

2023-08-29 Thread Paul Gevers

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

2024-01-28 Thread Paul Gevers

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

2024-02-04 Thread Paul Gevers

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

2022-02-12 Thread Paul Gevers

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.

2022-02-17 Thread Paul Gevers

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.

2022-02-24 Thread Paul Gevers

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

2022-02-28 Thread Paul Gevers

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.

2022-04-02 Thread Paul Gevers

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)

2022-04-10 Thread Paul Gevers

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

2022-05-02 Thread Paul Gevers

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

2022-05-31 Thread Paul Gevers

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

2022-07-05 Thread Paul Gevers

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

2022-07-09 Thread Paul Gevers

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

2022-07-24 Thread Paul Gevers

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

2022-07-31 Thread Paul Gevers
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

2022-08-09 Thread Paul Gevers

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.

2022-09-08 Thread Paul Gevers

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

2024-10-15 Thread Paul Gevers

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

2024-10-23 Thread Paul Gevers

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

2024-10-30 Thread Paul Gevers

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

2024-09-19 Thread Paul Gevers

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

2024-09-30 Thread Paul Gevers

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

2024-12-28 Thread Paul Gevers

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

2024-12-13 Thread Paul Gevers

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

2024-12-20 Thread Paul Gevers

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

2025-01-23 Thread Paul Gevers

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

2025-01-24 Thread Paul Gevers

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 sorting score ...
186s... done
186s Elapsed time at end of score sort: real: 0.003s, CPU: 0.001s
186s --Csound version 6.18 (double samples) 2024-08-21
186s [commit: none]
186s libsndfile-1.2.2
186s graphics suppressed, ascii substituted
186s sr = 44100.0, kr = 44100.000, ksmps = 1
186s 0dBFS level = 32768.0, A4 tuning = 440.0
186s orch now loaded
186s audio buffered in 256 sample-frame blocks
186s writing 512-byte blks of shorts to test.wav (WAV)
186s SECTION 1:
186s new alloc for instr 1:
186s B  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:  11564.5
186s   overall samples out of range:0
186s 0 errors in performance
186s Elapsed time at end of performance: real: 0.278s, CPU: 0.015s
186s 256 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

2025-04-10 Thread Paul Gevers

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

2025-02-14 Thread Paul Gevers

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

2025-07-04 Thread Paul Gevers

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'

2025-08-03 Thread Paul Gevers

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