Bug#527429: freqtweak: Build-Depends on libjack0.100.0-dev
Source: freqtweak Version: 0.7.0~cvs20070605-2 Severity: minor User: pkg-multimedia-maintain...@lists.alioth.debian.org Usertags: drop-versioned-libjack Hi, Your package build-depends upon libjack0.100.0-dev, which will dissappear in an upcoming upload of the Jack Audio Connection Kit. The correct package to depend upon is libjack-dev. Your package will not fail to build once the new jack is uploaded, because libjack-dev Provides libjack0.100.0-dev, and thus you don't need to do an upload just for this, but we would like to drop the Provides at some point. If you could change the build-dependency in a following upload, it would be greatly appreciated. -- Saludos, Felipe Sateler On behalf of the Debian Multimedia Maintainers. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527410: fluidsynth: Build-Depends on libjack0.100.0-dev
Source: fluidsynth Version: 1.0.8-2 Severity: minor User: pkg-multimedia-maintain...@lists.alioth.debian.org Usertags: drop-versioned-libjack Hi, Your package build-depends upon libjack0.100.0-dev, which will dissappear in an upcoming upload of the Jack Audio Connection Kit. The correct package to depend upon is libjack-dev. Your package will not fail to build once the new jack is uploaded, because libjack-dev Provides libjack0.100.0-dev, and thus you don't need to do an upload just for this, but we would like to drop the Provides at some point. If you could change the build-dependency in a following upload, it would be greatly appreciated. -- Saludos, Felipe Sateler On behalf of the Debian Multimedia Maintainers. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527431: jack-tools: Build-Depends on libjack0.100.0-dev
Source: jack-tools Version: 0.0.2-6 Severity: minor User: pkg-multimedia-maintain...@lists.alioth.debian.org Usertags: drop-versioned-libjack Hi, Your package build-depends upon libjack0.100.0-dev, which will dissappear in an upcoming upload of the Jack Audio Connection Kit. The correct package to depend upon is libjack-dev. Your package will not fail to build once the new jack is uploaded, because libjack-dev Provides libjack0.100.0-dev, and thus you don't need to do an upload just for this, but we would like to drop the Provides at some point. If you could change the build-dependency in a following upload, it would be greatly appreciated. -- Saludos, Felipe Sateler On behalf of the Debian Multimedia Maintainers. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#796588: adjtimex: Has init script in runlevel S but no matching service file
Package: adjtimex Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service Hi, Your package adjtimex has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org -- [1] http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ [763315] https://bugs.debian.org/763315 [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
Bug#796630: rdnssd: Has init script in runlevel S but no matching service file
Package: rdnssd Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service Hi, Your package rdnssd has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org -- [1] http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ [763315] https://bugs.debian.org/763315 [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
Bug#796635: nvi: Has init script in runlevel S but no matching service file
Package: nvi Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service Hi, Your package nvi has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org -- [1] http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ [763315] https://bugs.debian.org/763315 [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
