Bug#987874: [pre-approval] unblock: osspd/1.3.2-12
Hi Simon, On Thu, 10 Jun 2021 at 17:27:48 +0200, Paul Gevers wrote: If you really think another upload is too much hassle, you could convince us to unblock regardless if you build twice and show with diffoscope that the compat bump doesn't impact the (binary) packages at all. I'm not the maintainer, but I'd like to see osspd get into bullseye: it's good to have around for the benefit of old binary-only games, some of which are supported by game-data-packager. Unfortunately the compat bump from 9 to 13 does make a difference to the built binaries (mostly due to the addition of dh_dwz and the switch from dh_installinit to dh_systemd for systemd units, I think). Ralf, would you accept an NMU with the compat level bump reverted? Sure. I don't know what the process is for this, but if you want to fix osspd in bullseye, feel free to do whatever is necessary, and then please let me know what I have to do to get the compat-level-13 version back into unstable after the bullseye release. :) Kind regards, Ralf
Bug#987874: [pre-approval] unblock: osspd/1.3.2-12
Dear release team,
osspd maintainer here. Version 1.3.2-12 has hit unstable now that my new key is
finally in the keyring.
> diff --git a/debian/changelog b/debian/changelog
> index c412732..9481d07 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,17 @@
> +osspd (1.3.2-12) unstable; urgency=low
> +
> + [ Sébastien Noel ]
> + * cherrypick 2 commits from upstream GIT:
> ++ d/p/GIT-fix-adsp_se.patch
> ++ d/p/GIT-fix-compiler-warnings.patch
> + * Add workaround for pulseaudio >= 13
> +d/p/Hack-to-work-with-modern-PulseAudio.patch (Closes: #986662)
> +
> + [ Ralf Jung ]
> + * Switch to debhelper compat level 13.
Changing compat levels is no longer acceptable for bullseye. Please
revert.
Ah, that's a bummer. I was not aware of this policy, sorry for that.
Doing a revert upload sounds like a lot of hassle though that this package is
probably not worth -- so in this case it likely makes more sense to simply
remove the package from testing, and let it re-migrate after the release. The
current testing version (1.3.2-11) is broken with current PulseAudio, so
shipping it as-is makes no sense.
+Pre-Depends: ${misc:Pre-Depends}
Why?
Because lintian told me a pre-depends on "init-system-helpers" was missing, and
this was the easiest way to get that dependency.
Kind regards,
Ralf
Bug#733564: Re: Bug#733564: pu: apache2 with ECDHE support
Hi, This was added somewhere in a 2.3 version and so only part of a stable release in 2.4. This has been backported to 2.2.26 in the meantime: http://svn.apache.org/viewvc?view=revisionrevision=r1540727 more readable diff: https://github.com/apache/httpd/commit/058a25cdcb42572867d613ec13c68a350b9d57b6 This is what I intended to backport to wheezy, but I wanted to wait until 2.2.26 had actually been released and didn't get around to it, yet. Is there any news on this? I would really appreciate if I could set up my apache to use forward-secure cyphers with all clients (if alone to get rid of that minus in my SSL labs grade ;-) Kind regards Ralf -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533956bb.6070...@ralfj.de
Bug#704833: (pre-approval) unblock: virtuoso-opensource/6.1.4+dfsg1-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package virtuoso-opensource Hi Release-Team! We, the Qt/KDE team, would like you to check if the following changes are within what you are expecting for getting an unblock. The most important stuff was solving RC #704521 [2], but while looking at it I found other issues. The complete list of changes in the init script is: * I removed set -e from the script because (according to a footnote in policy [1]) lsb/init-functions is incompatible with that option. Furthermore, even the script itself did not deal with that option correctly, e.g., a non-0 exit code from start-stop-daemon would have terminated the script without proper logging. This also allowed for simplification where the $errcode was used previously. * The RC bug about stopping the daemon [2] is fixed in the stop_server function by using start-stop-daemon with a proper --retry argument, instead of killproc. The script has two modes of operation (one to use root, one with a dedicated user for the daemon), hence there are two branches in stop_server - I did not simplify this to keep the diff smaller. * The script used to INT the server due to [3], but according to upstream documentation [4] TERM should be used in rc.d scripts, so that's what it does now. * I removed reload_server and the reload directive because virtuoso does not support reloading (it used to print an error there, and then exit 0). * I removed force-stop since (a) it's not mandated or even recommended by anything (b) stop itself will already use KILL if TERM does not work and (c) it essentially just duplicated the retry-functionality of start-stop-daemon, but with way too long delays (60s). * The changes for the restart directive ensure that the script handles failure to stop the server appropriately. They also remove the 60s-delay between stop and start (which is no longer needed now that stop_daemon properly waits for virtuoso to quit). [1] http://www.debian.org/doc/debian-policy/footnotes.html#f81 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704521 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632060 [4] http://docs.openlinksw.com/virtuoso/signalsandexitcodes.html Diffstats: changelog| 15 control |5 - virtuoso-opensource-6.1.init | 131 ++- 3 files changed, 49 insertions(+), 102 deletions(-) Kind regards, Ralf Jung Debian Qt/KDE team unblock virtuoso-opensource/6.1.4+dfsg1-7 -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.6 (SMP w/4 CPU cores) diff -Nru virtuoso-opensource-6.1.4+dfsg1/debian/changelog virtuoso-opensource-6.1.4+dfsg1/debian/changelog --- virtuoso-opensource-6.1.4+dfsg1/debian/changelog 2013-02-25 09:49:36.0 -0300 +++ virtuoso-opensource-6.1.4+dfsg1/debian/changelog 2013-04-06 10:29:22.0 -0300 @@ -1,3 +1,18 @@ +virtuoso-opensource (6.1.4+dfsg1-7) UNRELEASED; urgency=low + + [ Lisandro Damián Nicanor Pérez Meyer ] + * Add Sune and myself to Uploaders. + + [ Ralf Jung ] + * init script: Use start-stop-daemon (Closes: 704521) + * init script: Do not use set -e, that's incompatible with +lsb/init-scripts + * init script: Stop attemtping to restart when stopping failed + * Change maintainer to Debian Krap team + * Remove obsolete DM-Upload-Allowed + + -- Debian Krap Maintainers debian-qt-...@lists.debian.org Thu, 04 Apr 2013 17:04:31 +0200 + virtuoso-opensource (6.1.4+dfsg1-6) unstable; urgency=low * Add safer-timeout.patch, avoids random FTBFS'es. These random FTBFS'es diff -Nru virtuoso-opensource-6.1.4+dfsg1/debian/control virtuoso-opensource-6.1.4+dfsg1/debian/control --- virtuoso-opensource-6.1.4+dfsg1/debian/control 2013-02-02 01:57:32.0 -0300 +++ virtuoso-opensource-6.1.4+dfsg1/debian/control 2013-04-06 10:29:22.0 -0300 @@ -1,8 +1,9 @@ Source: virtuoso-opensource Section: database Priority: optional -Maintainer: José Manuel Santamaría Lema panfa...@gmail.com -DM-Upload-Allowed: yes +Maintainer: Debian Krap Maintainers debian-qt-...@lists.debian.org +Uploaders: Lisandro Damian Nicanor Pérez Meyer lisan...@debian.org, + Sune Vuorela s...@debian.org Standards-Version: 3.9.3 Homepage: http://virtuoso.openlinksw.com/wiki/main/Main/ Vcs-Browser: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-virtuoso/pkg-virtuoso.git diff -Nru virtuoso-opensource-6.1.4+dfsg1/debian/virtuoso-opensource-6.1.init virtuoso-opensource-6.1.4+dfsg1/debian/virtuoso-opensource-6.1.init --- virtuoso-opensource-6.1.4+dfsg1/debian/virtuoso-opensource-6.1.init 2013-01-21 22:45:48.0 -0300 +++ virtuoso-opensource-6.1.4+dfsg1/debian/virtuoso-opensource-6.1.init 2013-04-06 10:28:46.0 -0300 @@ -54,11 +54,6 @@ # at /etc/default
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
Hi, As we are not going to get libxvmc turned to multi-arch for wheezy (see #640499) I'm now trying another approach with minimal changes to the libxvmc package: Related to this, there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5062fcae.2000...@ralfj.de
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
Hi, As we are not going to get libxvmc turned to multi-arch for wheezy (see #640499) I'm now trying another approach with minimal changes to the libxvmc package: Related to this, there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687373 Not so much related, as a proposed alternative, afaics? The maintainers appear to have made their opinion quite clear in #640499 on the originally suggested approach, however... You mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#66 ? He didn't say he's opposed to the patch, just that the release team might not let it through. The release team didn't reply (or I missed it?). libcap2 multiarchification was let in though (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684647), and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681717 looks like a similar case which has not yet been decided on (multiarchification needed to prevent regression from Squeeze for a large usergroup - even larger than this one, which only affects users of the proprietary NVidia driver). Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506303fa.7060...@ralfj.de
Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package
Hi, Not so much related, as a proposed alternative, afaics? The maintainers appear to have made their opinion quite clear in #640499 on the originally suggested approach, however... You mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#66 ? No, I meant http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499#149 Ah, that one. I must have missed a release manager saying that then - I don't know your names ;-) He didn't say he's opposed to the patch, just that the release team might not let it through. The release team didn't reply (or I missed it?). libcap2 multiarchification was let in though (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684647), and I'm aware of that. :-) (see the release team members involved in that discussion). Oh, saw that name already... ;-) That's also a different situation; libcap2 is required to allow us to get rid of the monolithic ia32-libs. Essentially, this is the case here, too: Getting git of libgl1-nvidia-glx-ia32, as it depended on ia32-libs (and, as reported by Andreas [1], can't be built with the multiarchified ia32-libs). So removing ia32-libs is the cause for this breakage. libxvmc was not part of ia32-libs so libgl1-nvidia-glx-ia32 lacked that dependency, but now that we must use libgl1-nvidia-glx:i386 and the proper automatically generated dependencies are used for all architectures, libxvmc is needed in a foreign-arch version as well, in one way or another. Kind regards, Ralf [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684871#27 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506309b5.5010...@ralfj.de
Bug#681717: Re: Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Hi, Release note that this bug blocks sound from working in wine and other i386 applications on amd64 in wheezy for many configurations (including mine). That is because libopenjpeg2 is required by libavcodec53 which is required by libasound2-plugins, which I need in both amd64 and i386 flavours to get sound to work in both 64 and 32 bit applications. Indeed this would be a regression compared to Squeeze, where lib32asound-plugins was available. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5061c651.40...@ralfj.de
