Bug#1067555: O: ffmpegthumbnailer -- fast and lightweight video thumbnailer
Package: wnpp Control: affects -1 + src:ffmpegthumbnailer X-Debbugs-Cc: ffmpegthumbnai...@packages.debian.org Severity: normal I intend to orphan the ffmpegthumbnailer package. I no longer use this package anymore. Its upstream is still active though the pace of releasing new versions is slow. The package description is: FFmpegthumbnailer is a lightweight video thumbnailer that can be used by file managers to create thumbnails for your video files. The thumbnailer uses ffmpeg to decode frames from the video files, so supported videoformats depend on the configuration flags of ffmpeg. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1051804: aom: Autopkgtest regression on s390x with aom v3.7.0
Source: aom Version: 3.7.0-1~exp1 Severity: serious Forwarded: https://bugs.chromium.org/p/aomedia/issues/detail?id=3487 Current aom 3.7.0 will raise autopkgtest regression on s390x. The following commands will raise an error: ffmpeg -y -f lavfi -i testsrc=duration=1:size=320x240:rate=30 -pix_fmt yuv420p input.y4m aomenc -o encoded.webm input.y4m aomdec -o decoded.yuv encoded.webm the error output of aomdec is as follows: Warning: Failed to decode frame 1: Corrupt frame detected Warning: Additional information: Invalid intrabc dv It is believed to be some endian handling error in the source code, and the bug is forwarded upstream pending investigation. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1036461: Please update to at least v7.0.1
Hi, 在 2023-06-26星期一的 20:18 -0400，Nicholas D Steeves写道： > Hello, > > Boyuan Yang writes: > > > 在 2023-05-22星期一的 20:55 -0400，Nicholas D Steeves写道： > > > Roman Lebedev writes: > > > > > We could do bookworm-backport for easyeffects after Debian 12 release, no > > problem. The package belongs to Multimedia Team from the very beginning; its > > packaging repo can be moved to salsa multimedia-team at anytime. > > Would you please move that repo? I requested this from the salsa admins > on IRC, but didn't receive a reply. I'll CC them now. > > Other than that, easyeffects 7.0.1-1 is now in testing and can be > backported. I've been testing in on bookworm since I made the upload to > experimental, and it works well. Looks like Non-Salsa-admins cannot move repo out of Debian group through https://salsa.debian.org/debian/easyeffects/edit . Non-Salsa-admins cannot delete repos under Debian group either. On the other hand, bookworm-backports is not open yet according to https://lists.debian.org/debian-backports/2023/06/msg00016.html . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1038827: libwebm: Failed tests in big-endian architectures
Source: libwebm Version: 1.0.0.29-1 Tags: sid Severity: important X-Debbugs-CC: debian-s...@lists.debian.org debian-h...@lists.debian.org debian-powe...@lists.debian.org debian-sp...@lists.debian.org vasek.ge...@gmail.com Hi all, Package libwebm was introduced into Debian in 2021 for .webm support (and to avoid library vendor copies). However, its unit test has been broken on big-endian architectures since very beginning as shown in buildd page at https://buildd.debian.org/status/package.php?p=libwebm (s390x/hppa/powerpc/ ppc64/sparc64 for 1.0.0.30-2 and earlier), causing FTBFS. Currently an convenient copy of libwebm is bundled and embedded in src:aom, and embedded libwebm lacks unit tests. When I am working on src:aom and trying to replace bundled libwebm with the packaged one, current failed unit tests in libwebm will need some handling, or at least in the release archtiecture (s390x, such as https://buildd.debian.org/status/fetch.php?pkg=libwebm=s390x=1.0.0.30-2=1687373358=0 ): == ./testing/mkvmuxer_tests.cc:863: Failure Expected equality of these values: muxer_mm.luminance_min() Which is: 30 parser_mm->luminance_min Which is: 0 ./testing/mkvmuxer_tests.cc:864: Failure Expected equality of these values: muxer_mm.luminance_max() Which is: 40 parser_mm->luminance_max Which is: 0 ./testing/mkvmuxer_tests.cc:865: Failure Expected equality of these values: muxer_mm.r()->x() Which is: 0.1 parser_mm->r->x Which is: 0 ./testing/mkvmuxer_tests.cc:866: Failure Expected equality of these values: muxer_mm.r()->y() Which is: 0.2 parser_mm->r->y Which is: 0 ./testing/mkvmuxer_tests.cc:867: Failure Expected equality of these values: muxer_mm.g()->x() Which is: 0.1 parser_mm->g->x Which is: 0 ./testing/mkvmuxer_tests.cc:868: Failure Expected equality of these values: muxer_mm.g()->y() Which is: 0.2 parser_mm->g->y Which is: 0 ./testing/mkvmuxer_tests.cc:869: Failure Expected equality of these values: muxer_mm.b()->x() Which is: 0.1 parser_mm->b->x Which is: 0 ./testing/mkvmuxer_tests.cc:870: Failure Expected equality of these values: muxer_mm.b()->y() Which is: 0.2 parser_mm->b->y Which is: 0 ./testing/mkvmuxer_tests.cc:871: Failure Expected equality of these values: muxer_mm.white_point()->x() Which is: 0.1 parser_mm->white_point->x Which is: 0 ./testing/mkvmuxer_tests.cc:872: Failure Expected equality of these values: muxer_mm.white_point()->y() Which is: 0.2 parser_mm->white_point->y Which is: 0 [ FAILED ] MuxerTest.Colour (0 ms) [ RUN ] MuxerTest.ColourPartial [ OK ] MuxerTest.ColourPartial (0 ms) [ RUN ] MuxerTest.Projection ./testing/mkvmuxer_tests.cc:930: Failure Expected equality of these values: muxer_proj.pose_yaw() Which is: 1 parser_proj->pose_yaw Which is: 0 ./testing/mkvmuxer_tests.cc:931: Failure Expected equality of these values: muxer_proj.pose_pitch() Which is: 2 parser_proj->pose_pitch Which is: 0 ./testing/mkvmuxer_tests.cc:932: Failure Expected equality of these values: muxer_proj.pose_roll() Which is: 3 parser_proj->pose_roll Which is: 0 [ FAILED ] MuxerTest.Projection (0 ms) === I am looking for help from porters with experience in big-endian architectures on debugging of the test failures. Given the high popcon of reverse dependencies (src:aom, 3+), I may allow unittest failures for now but still keep this bug report open against src:libwebm. Any help would be appreciated. Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1038801: libwebm: ENABLE_IWYU build flag not effective
Source: libwebm Version: 1.0.0.29-1 Severity: minor Tags: sid X-Debbugs-CC: vasek.ge...@gmail.com Dear Debian libwebm package maintainers, In debian/rules it tries to define ENABLE_IWYU flag. However, buildd log https://buildd.debian.org/status/package.php?p=libwebm shows that it is not working: -- Ignoring ENABLE_IWYU because reasons: -- iwyu_path=iwyu_path-NOTFOUND -- iwyu_tool_path=iwyu_tool_path-NOTFOUND -- PYTHONINTERP_FOUND=TRUE -- See README.libwebm for more information. Please review the packaging instruction and solve the problem. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1036461: Please update to at least v7.0.1
Hi, 在 2023-05-22星期一的 20:55 -0400，Nicholas D Steeves写道： > Roman Lebedev writes: > > > Package: easyeffects > > Version: 7.0.0-1 > > Severity: normal > > > > Dear maintainer, out of all the improvements in newer versions, there is > > one > > change that brings high UX improvements for doing live audio post- > > processing: > > "exposing support for the "the Min and Max sidechain modes" > > https://github.com/wwmm/easyeffects/commit/3cf99f74747b5a318e6818423b89f867ceaac988 > > https://github.com/wwmm/easyeffects/issues/2042 > > which adds UI for lsp-plugin's > > https://github.com/sadko4u/lsp-plugins/issues/274 > > which was implemented in lsp-plugins v1.2.4 (and debian has v1.2.5) > > > > It would be really great to update! > > > > Easyeffects v7.0.1 is v7.0.0 plus 339 commits, and it looks like these > are mostly translation-related, plus a mix of feature, refactoring, and > bug fix commits. The translations and bug fixes are ok, but at this > stage of the upcoming bookworm (Debian 12) release, v7.0.1 cannot be > imported in its entirety: > https://release.debian.org/testing/freeze_policy.html > > It was arguably too late at the beginning of the soft freeze > (2023-02-12). That said, "Only small, targeted fixes" is up to > maintainer discretion, so it may have been possible before 2023-03-12. > Now that we're in the "hard freeze", and because easyeffects doesn't > have autpkgtests, someone on the Release Team would need to unblock an > upload of v7.0.1; The Release Team is almost certainly not going to sign > off on such a large delta, so the best case scenario appears to be to > request a bookworm-backport of easyeffects after the bookworm release. > That will become possible about a week after this bug is closed (were I > to guess, probably July or August). > > Boyuan Yang: Would you please acknowledge if this package belongs to the > Multimedia Team? It's still in Debian/collab-maint namespace, and if > it's team-maintained then it should be moved here: > > https://salsa.debian.org/multimedia-team We could do bookworm-backport for easyeffects after Debian 12 release, no problem. The package belongs to Multimedia Team from the very beginning; its packaging repo can be moved to salsa multimedia-team at anytime. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1014934: libgav1: Please package new version 0.18.0
Source: libgav1 Version: 0.17.0-1 Severity: normal Tags: sid X-Debbugs-CC: xialei...@gmail.com Dear Debian libgav1 package maintainer, A new upstream release 0.18.0 is available at https://chromium.googlesource.com/codecs/libgav1/+/refs/tags/v0.18.0 . Please consider packaging the new upstream release. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Status of lsp-plugins package
Hi Dennis, I noticed that package lsp-plugins was not updated and had an RC bug of armhf build failure, and applied Ubuntu's patch to fix it in the new team upload. Meanwhile, I noticed that you prepared the new version in the git packaging repository. While I would like to help with the packaging, I am not sure whether the code currently in the packaging repository is ready. It would be great if you can provide more hints on the packaging progress. If you need package sponsorship that involves the NEW queue, please feel free to let me know. Thanks for your package maintenance work! Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1006277: RFP: easyeffects -- Audio effects for PipeWire applications (formerly - pulseeffects)
X-Debbugs-Cc: debian-multimedia@lists.debian.org lebedev...@gmail.com Hi, On Tue, 22 Feb 2022 19:27:22 +0300 Roman Lebedev wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-multimedia@lists.debian.org, by...@debian.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name : easyeffects > Version : 6.2.3 > Upstream Author : wwmm > * URL : https://github.com/wwmm/easyeffects > * License : GNU GPL v3 > Programming Lang: C++ > Description : Audio effects for PipeWire applications (formerly - pulseeffects) > > The existing Debian package named pulseeffects is dead upstream, > and the new versions are called easyeffects. > > I'm not sure whether pulseeffects can be used with pipewire, > or of easyeffects can be used with pulseaudio, > but i think they can simply be packaged in parallel, > at least for a bit. > > Lately, i've been using pulseeffects more and more, so i believe > that packaging easyeffects may make the migration to pipewire > almost seamless. Please check out https://github.com/wwmm/easyeffects/issues/1000 and https://bugs.debian.org/980839 for more information. Any help would be appreciated. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#995753: qimgv: Crashes trying to display video
Control: notfound 995753 1.0.2-1 Control: close 995753 On Fri, 08 Oct 2021 15:51:52 +0300 Vladimir K wrote: > Confirming, the cause is partial mesa upgrade. > Got the full mesa set from unstable today, no longer having this issue. Given that the core issue is partial mesa upgrade which has been solved long ago, I am closing this issue. If you find similar bugs, please open a new bug report. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#992495: segfault in av1_cyclic_refresh_free()
Control: tags -1 +moreinfo +unreproducible Hi, I could not reproduce this issue on current Debian 11 Stable, Debian Testing and Debian Unstable. Could you verify that this is still crashing on your devices? If yes, please also consider providing the exact .jpg file that would trigger the crashing. Thanks, Boyuan Yang On Thu, 19 Aug 2021 13:04:23 +0200 Philipp Marek wrote: > Package: libaom0 > Version: 1.0.0.errata1-3 > Severity: normal > X-Debbugs-Cc: phil...@marek.priv.at > > When using libaom0 (via ImageMagick's "convert" or gimp), it crashes > when writing a avif: > > > $ gdb ... --args convert 20210812_215114.jpg 20210812_215114.avif > > Thread 1 "convert" received signal SIGSEGV, Segmentation fault. > 0x74451b64 in av1_cyclic_refresh_free (cr=0x0) at ./av1/encoder/aq_cyclicrefresh.c:83 > 83 ./av1/encoder/aq_cyclicrefresh.c: Datei oder Verzeichnis nicht gefunden. > #0 0x74451b64 in av1_cyclic_refresh_free (cr=0x0) at ./av1/encoder/aq_cyclicrefresh.c:83 signature.asc Description: This is a digitally signed message part
Bug#997917: transition: aom
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: by...@debian.org debian-multimedia@lists.debian.org Severity: normal Dear Debian Release Team, I plan to start libaom transition as shown on the following transition tracker: https://release.debian.org/transitions/html/auto-aom.html The new version of libaom library has bumped SONAME (libaom0 -> libaom3) and needs a transition. There are 3 reverse build-dependencies, and I have verified that the build would still pass with the new libaom currently in experimental: * ffmpeg (ok) * libheif (ok) * gst-plugins-bad1.0 (ok) Example Ben file (the one currently on auto-aom page should be ok): title = "aom"; is_affected = .depends ~ "libaom3" | .depends ~ "libaom0"; is_good = .depends ~ "libaom3"; is_bad = .depends ~ "libaom0"; I expect it to be a smooth transition that only involves binNMUs. Please let me know if there are any concerns. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#997806: aom: possible ABI breakage; causes ffmpeg autopkgtests failures
Hi, On Sun, 24 Oct 2021 23:28:33 +0200 Sebastian Ramacher wrote: > Source: aom > Version: 1.0.0-errata1.avif-1 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > From ffmpeg's autopkgtest: > | [libaom-av1 @ 0x55ab8a773940] Failed to initialize encoder: ABI version mismatch Given that libaom 3.2.0 just passed the NEW queue, there's really no benefit on keeping version 1.0.0.errata1.avif and handling related ABI breaks. In Debian Sid, I will revert to the old libaom version (the same as in Debian Testing) and initiate a formal transition from libaom 1.x to libaom 3.x. Thanks for the report and let me know if there are any further issues (e.g., issues related to transition). Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Uploading taglib 1.12 onto Debian Sid
Hello all, After some really long testing and procrastination, I am (finally) uploading taglib v1.12 onto Debian Sid. You may examine its current status in Debian at https://tracker.debian.org/pkg/taglib . Since the new version came out 5 years after the last release, I believe there could be some new bugs popping up. If your package utilizes taglib (e.g., handles music file metadata and tags), you may want to do some testing, and please let me know if there are any regressions. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#972467: aom: Please package new upstream stable release (2.0.0)
Hi all, 在 2021-09-14星期二的 15:24 -0400，Boyuan Yang写道： > X-Debbugs-CC: d...@jones.dk jcowg...@debian.org > > On Sun, 18 Oct 2020 17:21:21 -0400 Boyuan Yang wrote: > > Source: aom > > Severity: important > > Version: 1.0.0.errata1-3 > > Tags: sid > > X-Debbugs-CC: jcowg...@debian.org > > > > Dear Debian libaom maintainers, > > > > There is a new upstream release for libaom (2.0.0). This new release > > contains tons of fixes and new features and is needed by libavif. > > Please consider packaging it. > > Now that Debian 11 is out, we are still stuck with aom 1.0 series. I believe > it's worthwhile to work on pushing new aom into Debian. > > I will probably take a fresh start (i.e. use stock upstream source code and > drop debian/patches/*) with experimental and later into unstable as team > uploads, and add patches when needed. James: if you find any of these steps > inappropriate, please let me know immediately. > > Thanks, > Boyuan Yang FYI: I worked on packaging the embedded library (third_party/libyuv), and it is currently in the NEW queue: https://ftp-master.debian.org/new/libyuv_0.0~git20210909.ed5a9c8-1.html and https://salsa.debian.org/debian/libyuv . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#972467: aom: Please package new upstream stable release (2.0.0)
X-Debbugs-CC: d...@jones.dk jcowg...@debian.org On Sun, 18 Oct 2020 17:21:21 -0400 Boyuan Yang wrote: > Source: aom > Severity: important > Version: 1.0.0.errata1-3 > Tags: sid > X-Debbugs-CC: jcowg...@debian.org > > Dear Debian libaom maintainers, > > There is a new upstream release for libaom (2.0.0). This new release > contains tons of fixes and new features and is needed by libavif. > Please consider packaging it. Now that Debian 11 is out, we are still stuck with aom 1.0 series. I believe it's worthwhile to work on pushing new aom into Debian. I will probably take a fresh start (i.e. use stock upstream source code and drop debian/patches/*) with experimental and later into unstable as team uploads, and add patches when needed. James: if you find any of these steps inappropriate, please let me know immediately. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#994144: libavif-dev: Version in bullseye provides broken pkgconfig file (libdir wrong)
Package: libavif-dev Version: 0.8.4-2 Severity: important Control: fixed -1 0.9.2-1 In libavif before v0.9.2, the pkgconfig file shipped by the library is broken under multiarch setup due to hardcoding $prefix/lib/ as libdir. This bug is fixed in libavif/0.9.2. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#992818: RFH: taglib -- audio meta-data library
Package: wnpp Severity: normal X-Debbugs-CC: debian-de...@lists.debian.org debian-multimedia@lists.debian.org Hi all, I request help in maintaining package taglib and doing upgrade to new upstream version (1.12). Taglib is an essential library to process audio metadata with very high popcon (> 95900). I initially adopted this package (thanks to the ITS procedure) to fix the infamous longstanding bug https://bugs.debian.org/915281 . When upstream released new version 1.12, I realized that I don't have enough knowledge to review upstream changes, existing packaging instructions and carry-over patches under debian/ directory. Therefore, I welcome anyone with knowledge of multimedia to co-maintain this package and/or have it updated in Debian. The git packaging repo is placed under multimedia-team namespace ( https://salsa.debian.org/multimedia-team/taglib ). Feel free to let me know if you need access to it. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#987214: ocp: Build-depends on transitional dummy package ttf-unifont
Source: ocp Severity: important Version: 1:0.2.2+ds-1 X-Debbugs-CC: gur...@phys.ethz.ch Dear Debian ocp package maintainer, Your package build-depends on transition dummy package ttf-unifont which will be removed in the future. Please use the real package fonts-unifont instead. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#978854: libmypaint: ftbfs with autoconf 2.70
Control: forwarded -1 https://github.com/mypaint/libmypaint/issues/178 I have prepared a dirty workaround and forwarded it to upstream. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#978047: debian-multimedia: A source-only upload is required for testing migration
Source: debian-multimedia Version: 0.9 Severity: important X-Debbugs-CC: rossgam...@debian.org siret...@tauware.de Dear Debian debian-multimedia package maintainer, The latest upload of package debian-multimedia was not a source-only upload. As a result, v0.9 did not migrate to Testing. If this issue is not fixed, the new version will miss Debian 11 release due to approaching soft and hard freeze. Please make another source-only upload as described in https://wiki.debian.org/SourceOnlyUpload . Thanks! -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#972467: aom: Please package new upstream stable release (2.0.0)
Source: aom Severity: important Version: 1.0.0.errata1-3 Tags: sid X-Debbugs-CC: jcowg...@debian.org Dear Debian libaom maintainers, There is a new upstream release for libaom (2.0.0). This new release contains tons of fixes and new features and is needed by libavif. Please consider packaging it. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#639104: taglib: Missing static library.
Control: tags -1 -wontfix Control: tags -1 +help On Sat, 31 Aug 2013 01:59:24 +1000 Reuben wrote: > > Why is it so strong as 'should'? According to what? On the same basis > you > > could argue that all libraries in Debian should do this but you won't > get very > > far with this reasoning. Debian *prefers* shared libraries because > you can > > provide sane security support for them. > > Because it is in the package description > (http://packages.debian.org/sid/libtagc0-dev): > "This is the development package which contains headers and static libraries > for the TagLib Audio Meta-Data Library." Hi, I'm writting to let you know that I strongly disagree with the position that the old package maintainer held. Even though Debian prefers shared libraries, Debian's preference on its internal policy should not block various external needs from users. I still consider this bug as a valid feature request. Now that I have taken over the package maintainership (and have it team- maintained under the Multimedia Team), I will accept patches for adding a static library but I do not have time to implement it myself. I strongly recommend having your patch sent to taglib upstream first and give a reference link in this bug report after that. Any help would be appreciated. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#940732: pulseeffects: almost all plugins broken in current sid
Hi Marcus, 在 2020-07-23星期四的 23:16 +0200，Marcus写道： > Package: pulseeffects > Version: 4.7.3-1 > Followup-For: Bug #940732 > X-Debbugs-Cc: pleasespamtothis...@gmx.de > > Dear Maintainer, > > I don't know when it happened exactly, but the "pulseeffects" plugins seem > to be broken again. > I was using many plugins 1 to 2 months ago and they were working fine. > After one of the recent updates - suddenly most plugins aren't available > anymore I believe your problem should be different from the one at https://bugs.debian.org/940732 . Besides, I cannot reproduce your problem on my local Sid machine. My suggestion is to purge everything about pulseeffects and lsp-plugins first and make a clean reinstallation. Please try with the following commands: sudo apt update sudo apt purge '*pulseeffects*' '*lsp-plugin*' sudo apt autoremove --purge sudo apt install pulseeffects --install-recommends (After that, reboot your system once.) Now please check whether running /usr/bin/pulseeffects will raise errors or not. If the problem persists, please submit a *new* bug report instead of replying this one. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962606: csound: Build-depends on removed package ttf-dejavu
Source: csound Severity: grave Version: 1:6.14.0~dfsg-5 X-Debbugs-CC: fsate...@debian.org forrest.cah...@gmail.com Dear Debian csound maintainers, Your package csound build-depends on package ttf-dejavu, which is a transitional package that has been removed since the upload of fonts- dejavu/2.37-2. Please adjust the build-dependency information and use package name fonts-dejavu. Please note that ttf-dejavu and fonts-dejavu provides the fonts under *different* paths. Please review your package and make sure that the hardcoded paths (if any) have been updated accordingly. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#956672: rtkit activation fails, because service unit is installed at the wrong place
Control: tags -1 -pending +patch
X-Debbugs-CC: sate...@debian.org
Alright -- I think I got the reason.
Since we switched to meson buildsystem, all variable handling happens in
meson.build. Starting at
https://salsa.debian.org/multimedia-team/rtkit/-/blob/0a0f6d58f792f8dcf38f9b0b4cf925e9f4f4337d/meson.build#L61
:
systemunitdir = ''
if systemunitdir == '' and systemd_dep.found()
systemunitdir = systemd_dep.get_pkgconfig_variable(
'systemdsystemunitdir',
default: '',
)
endif
if systemunitdir == ''
systemunitdir = get_option('libdir') / 'systemd' / 'system'
endif
Now librt does NOT build-depend on systemd. As a result, meson cannot find
/usr/share/pkgconfig/systemd.pc (provided by binary package systemd). This
makes systemd_dep.found() to return false. Finally systemunitdir will be given
as $libdir/systemd/system, which is wrong since $libdir is multi-archified.
I would propose to add systemd as build-dependency. Personally I am okay with
this, but downstream Devuan and other maintainers who want to keep away from
systemd might not be happy. Another choice is to patch the buildsystem. I'd
leave this decision to current rtkit maintainers.
Besides: it would also be great if an optional build-dependency libpolkit-
gobject-1-dev could be added as well.
--
Regards,
Boyuan Yang
On Tue, 14 Apr 2020 08:52:48 +0200 =?utf-8?b?R8OhYm9yIEdvbWLDoXM=?= <
gomb...@digikabel.hu> wrote:
> Package: rtkit
> Version: 0.13-2
> Severity: important
>
> Hi,
>
> syslog is full with:
>
> Apr 14 08:42:53 host dbus-daemon[940]: [system] Activating via systemd:
service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service'
requested by ':1.158' (uid=1000 pid=156197 comm="/usr/lib/firefox/firefox
-contentproc -childID 6 -")
> Apr 14 08:42:53 host dbus-daemon[940]: [system] Activation via systemd
failed for unit 'rtkit-daemon.service': Unit rtkit-daemon.service not found.
>
> ... and the reason is:
>
> # dpkg -L rtkit | grep rtkit-daemon.service
> /usr/lib/x86_64-linux-gnu/systemd/system/rtkit-daemon.service
>
> The unit file should be under /usr/lib/systemd/system.
signature.asc
Description: This is a digitally signed message part
Bug#956255: pulseeffects: Version 4.7.2+ needs libboost 1.72+
Source: pulseeffects Version: 4.7.1-1 Severity: important Tags: help According to https://github.com/wwmm/pulseeffects/issues/645 , pulseeffects with version 4.7.2+ needs new features provided by libboost 1.72 or higher. Since Debian has just started the preparation of transition onto boost 1.71, it could take a long time before boost 1.72 is available on Debian and pulseeffects version in Debian could be stuck here. If you have any good solution, please let me know. -- Best, Boyuan Yang
Bug#915386: Request to Join Debian Multimedia Team
Hi Garie, On Thu, 27 Feb 2020 11:16:20 -0600 "GMiller" wrote: > Hello: > > I hereby request permission to try to package fdk-aac 2.0.1. This > package also includes libfdk-aac-dev, which currently references > Bug#915386. > > My motivation for joining the Multimedia Team is solely the completion > of another Debian Bug#907576. I do not foresee much involvement with > the Multimedia Team beyond maintaining fdk-aac. 907576 requires the > newer libfdk-aac-dev 2.0.0, and thus my request to join you. > > My prior experience in Debian is limited to working on Bug#907576 for > another team. Note that I am not an official Debian Maintainer on any > Team. > > As instructed by your 'How to Join' page, I have created a Salsa > account and subscribed to the Multimedia mailing list. I have > previously filed a few Debian bugs. As for reviewing others work, I do > not believe I am qualified. > > I have previously read most of the Debian packaging procedures while > working on Bug907576. I am currently digesting the contents of the > Multimedia Teams 'DevelopPackaging' page. > > I will be clicking on the Team's 'Request to Join' page sometime after > I send this email. I have granted a "Maintainer" role to your Salsa account. Note that you may or may not do the work base on the Salsa git repo at https://salsa.debian.org/multimedia-team/fdk-aac . Please be aware that package fdk-aac is not a free software as determined by Debian and was put under non-free section, which means any software depending on it will have to be put either in contrib section or in non-free too. When you are working on the git packaging repository, please follow the suggestion at https://dep-team.pages.debian.net/deps/dep14 as well as the Multimedia team's guideline as documented at https://wiki.debian.org/DebianMultimedia/DevelopPackaging . When you have reached a milestone in packaging the new version, please have your work outcome uploaded onto mentors.debian.net for review and have other Debian Developers review your work. If you prefer not to use mentors.debian.net, you may also have the work ready in the git packaging repository on Salsa. If you have any immature work stored in Git repo, you may also put the work under your own namespace (at https://salsa.debian.org/GMiller-guest/) . -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
transition: libmypaint
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: jbi...@debian.org pkg-gnome-maintain...@lists.alioth.debian.org Dear Release Team, I am looking into initiating the transition as indicated in the automatic transition tracker: https://release.debian.org/transitions/html/auto-libmypaint.html . The only reverse (build-)dependency is GIMP. I have tested to rebuild GIMP against the new libmypaint and everything looks okay. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: Request to join the debian-multimedia team
Hi Jonas, 在 2020-02-19三的 18:32 +0100，Jonas Smedegaard写道： > [ dropping cc'ed people ] > > Hi Boyuan, > > Apologies on behalf of the 50+ owners in the Multimedia team for letting > you hang there for so long. > > You are now owner yourself in the team: Please help make it a more > pleasant experience for others by reacting when they similarly reqeust > access (and consider making them owners as well: evidently we are too > few taking responsibility in the team). Thanks! I can confirm it's working now. Collaboration is important and I will do my best :-) -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Request to join the debian-multimedia team
Dear debian-multimedia maintainers, I am interested in joining the debian-multimedia team. For concrete projects, I am interested in solving this infamous bug https://bugs.debian.org/906144 given that we now have the chance of uploading mypaint 2.0.0 and libmypaint 1.5.0 together. Besides, I am also interested in bringing package pulseeffects https://tracker.debian.org/pkg/pulseeffects currently maintained by me under debian-multimedia team maintenance. My request on joining Salsa multimedia-team has been submitted for several months without response. If you are a team maintainer, please consider accepting the request. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#875038: [lmms] Future Qt4 removal from Buster
A stable lmms 1.2.0 with Qt5 support is already released several months ago. Now it's about someone should be packaging it within Debian. Thanks, Boyuan Yang 在 2019-08-25日的 21:04 +0200，Moritz Mühlenhoff写道： > On Sun, Oct 14, 2018 at 03:16:27AM +0200, Javier Serrano Polo wrote: > > On Fri, 23 Mar 2018 18:23:51 +0800 Boyuan Yang <073p...@gmail.com> > > wrote: > > > lmms 1.2.0 is on its way. > > > > I will not package a candidate version unless this bug becomes serious. > > Efforts should be directed in helping upstream to release a stable > > version. > > This has now been bumped to serious last week. What's the plan here, > ship an interim version supporting Qt5 or remove lmms and re-introduce > it to Debian once a stable 2.0 release is out? > > Cheers, > Moritz > signature.asc Description: This is a digitally signed message part
Bug#907293: stops: Please consider making another upload and refreshing package
在 2018年8月28日星期二 EDT 上午6:56:13，Sebastian Ramacher 写道： > Hi Boyuan > > On 2018-08-28 10:49:48, Daniel James wrote: > > Hi Boyuan, > > > > > Dear stops maintainer (Hi Free Ekanayaka) > > > > Maintainer for this package is Debian Multimedia Team, it's just that > > Free was the last uploader. > > > > > I was cleaning up packages that hasn't receive any upload in Debian for > > > a long time and noticed that your package, stops, received no upload > > > since 2007, which is quite a long period of time. > > > > As I recall, this package is static data, and may not ever need to be > > updated upstream. Debian's version 0.3.0 is still the current release: > > http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html > > > > stops is a dependency of the active package > > https://packages.debian.org/sid/aeolus which has a new upstream release > > available (0.9.7). > > > > > Making uploads to stops might be necessary according to [1] since we > > > want to make Debian 100% reproducible in the future [2] and all > > > packages built before December 2016 will need a rebuild. > > > > Sounds good! Also #888669 might need looking at. I am not a Debian > > Developer but happy to help if I can find a sponsor. > > > > > I am also considering initiating the MIA procedure[3] (targeting > > > package only, not to the person because I know you look still active) if > > > there's no reply after certain period of time > > > > Hopefully that will not be necessary, aeolus is a unique software > > instrument and it would be a shame to lose it from Debian. > > The MIA procedure is for maintainers and not for packages. So I am not sure > what the intended goal is. Do you want to get get stops removed from the > archive? I would find asking for removal of packages maintainer by other > people that do not have an RC bug and have not been superseded rather > inappropriate. I am not proposing to remove this package; instead I was proposing of having MIA team involved and (orphan this package) / (have other maintainers taken this package care of) since monitoring packages that receive little care is also part of QA/MIA Team's job. I thought stops might be eligible to such arrangement since it received no upload in the past 11 years, which is No.3 oldest (!) package in the Debian archive. The reproducible-builds project as mentioned above is also another reason of having the package rebuilt. My personal idea is that packages in Debian should ideally be rebuilt every few years (or at least definitely every 10 years) since the packaging technology and .deb package formats are all evolving. I'm happy to provide with any kind of help that you might find necessary (including NMUs) but a concent from previous maintainers / uploaders will make the procedure more smoothly. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#907293: stops: Please consider making another upload and refreshing package
Package: stops Severity: wishlist X-Debbugs-CC: fr...@debian.org Dear stops maintainer (Hi Free Ekanayaka), I was cleaning up packages that hasn't receive any upload in Debian for a long time and noticed that your package, stops, received no upload since 2007, which is quite a long period of time. Making uploads to stops might be necessary according to [1] since we want to make Debian 100% reproducible in the future [2] and all packages built before December 2016 will need a rebuild. Meanwhile, It is unsure whether you are still actively maintaining this package and is willing to maintain it in the future after so many years. Besides, this package is using ancient packaging instructions (debhelper compat v5) and that needs refreshing. As a result, I am wondering if you could make another upload for package stops recently, ideally before the Buster freeze. Since it hasn't receive any upload for 11 years, I am also considering initiating the MIA procedure[3] (targeting package only, not to the person because I know you look still active) if there's no reply after certain period of time (e.g., 60 days). Thank you very much for your attention and understanding, -- Best Regards, Boyuan Yang [1] https://lists.debian.org/debian-devel/2018/05/msg00499.html [2] https://reproducible-builds.org/ [3] https://wiki.debian.org/Teams/MIA signature.asc Description: This is a digitally signed message part.
