similar to: Bug#1039422: xen: ships sysv-init script without systemd unit

Package: xen-utils-common Version: 4.17.0-1 Severity: normal Dear Xen Maintainers, xen-utils-common currently ships two /etc/init.d scripts (xen, xendomains) and relies on systemd-sysv-generator(8) to integrate with systemd (Debians default init system). Please improve the integration by providing native systemd unit files. When doing so, you can also take advantage of newer features, like

This is awesome! What needs to be done before this can make it to unstable? I’d love to help if there’s anything I can do. Stephen On Fri, Oct 5, 2018 at 8:00 PM Hans van Kranenburg <hans at knorrie.org> wrote: > On 10/05/2018 08:04 PM, Ian Jackson wrote: > > I have now finished totally rewriting the Xen package in Debian, from > > scratch. Amazingly as soon as I got a

Knorrie and I just discussed our plans for sid and buster, on the phone. Here's my notes of the discussion. Plan is to upload Knorrie's 4.11 packages to experimental, to make them more public, while we fix the bugs in them. There's a list of Salsa issues and the BTS bugs list. This duplication is not ideal. We agreed that new things should go to the BTS. For now we'll keep

I have now finished totally rewriting the Xen package in Debian, from scratch. Amazingly as soon as I got a package which was lintian-clean and would install, it worked first time ! I have generated 18 patches to go upstream which I have sent to xen-devel. There are two more, xenstore ABI patches, which need a bit of tidying up. There is still room for improvement but it is now clearly ready

Processing commands for control at bugs.debian.org: > reassign 1029998 xen Bug #1029998 [xen-utils-common] xen-utils-common: Please provide systemd units Bug reassigned from package 'xen-utils-common' to 'xen'. No longer marked as found in versions xen/4.17.0-1. Ignoring request to alter fixed versions of bug #1029998 to the same values previously set > forcemerge 1039422

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

2016-07-10 2:12 GMT+02:00 Andrew Bartlett <abartlet at samba.org>: > On Sat, 2016-07-09 at 11:27 +0200, Marc Muehlfeld wrote: > > Hello, > > > > Am 09.07.2016 um 09:14 schrieb Rowland penny: > > > > What is the purpose of the option > > > > * > > > > **--with-**systemd** > > > > ****Enable****systemd****integration* >

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

hi there, first, kudos to Scott. You guy rock with this revolutionizing (and so logic) idea ;-) next, a personal point of view about the lack of upstream adoption of upstart: I wanted to provide an upstart script for NUT for some time, but never found enough matching example to do so. the embedded scripts only address inittab, and the replacement-initscripts are unreachable (see below) and far

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: Nice!

kevin martin wrote: > not sure why having the systemd notify code in openssh as a > configure time option would be such a bad thing. At the very least it introduces a dependency on libsystemd into sshd, which is undesirable for reasons of security and convenience. The principle of "you are done when you can not remove any more" confirms that it is unwise to add dependencies

Hans van Kranenburg writes ("Re: [PATCH 08/13] xen init script: rewrite xenstored start logic"): > So the question we should answer first is: What do we allow the user to > set as value? /bin/bash? And how should the init script deal with that? If they specify an absolute path, it should be used. Eg, /home/alice/Xen/xen/tools/xenstore/xenstore If the user specifies /bin/bash

Am 23.11.2017 um 23:16 schrieb Arnab Roy: > No dice :( removed as suggested updated unit file looks like this "Type=notify" can not work until systemd-support was successful built which does not seem to be the case looking at the starting posts! > [Unit] > Description=KKonnect KHIPU-NETWORKS Service > After=syslog.target network.target > > [Service] >

Package: xen-utils-common Version: 4.4.1-9+deb8u1 Severity: normal With SE Linux it's desirable to give utilities and daemons the minimum privileges. That includes not permitting general utilities to create directories under /var/run. I think it would be best if /var/run/xen-hotplug was created by an init script such as /etc/init.d/xen (or by systemd-tmpfiles when using systemd units).

On 12/29/2015 10:13 AM, Mike - st257 wrote: > Hello CentOS List, > > I have a server that has SysV script supplied by a hardware manufacturer, > which is not functioning properly. From my reading, systemd-sysv-generator > should handle them (like it did for Dell OpenManage software which supplied > SysV init scripts). > >

On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale <jcasale at activenetwerx.com > wrote: > Instead of converting the sysv script, you could trivially write your own, > the following > was tested against about 6 SNMP queries, the service stops and starts as > expected. > That's certainly an option. One that I was prepared to resort to. But curiosity has the best of me ...

On 30 Dec 2015 00:55, "Mike - st257" <silvertip257 at gmail.com> wrote: > > On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale < jcasale at activenetwerx.com > > wrote: > > > Instead of converting the sysv script, you could trivially write your own, > > the following > > was tested against about 6 SNMP queries, the service stops and starts as >

On 30 December 2015 at 14:23, Mike - st257 <silvertip257 at gmail.com> wrote: > Consolidating my reply to both James and Gordon in one message. > > > On Wed, Dec 30, 2015 at 2:38 AM, James Hogarth <james.hogarth at gmail.com> > wrote: > > > On 30 Dec 2015 00:55, "Mike - st257" <silvertip257 at gmail.com> wrote: > > > > > > On

Instead of converting the sysv script, you could trivially write your own, the following was tested against about 6 SNMP queries, the service stops and starts as expected. You may want to purge the sysv remnants. # cat /etc/systemd/system/lsi_mrdsnmpd.service [Unit] Description=LSI SNMP Agent startup/shutdown script Requires=network.target Requires=snmpd.service After=network.target