[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#862873: marked as done (O: vblade-persist -- create/manage supervised AoE exports)

Your message dated Mon, 11 Feb 2019 15:51:14 +0000
with message-id <E1gtDrW-0007jz-5N@fasolo.debian.org>
and subject line Bug#921984: Removed package(s) from unstable
has caused the Debian Bug report #862873,
regarding O: vblade-persist -- create/manage supervised AoE exports
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
862873: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862873
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: wnpp
Severity: normal

I'm both upstream and the debian maintainer for vblade-persist.  I
don't currently use it, and i don't have much time for it.
Furthermore, it relies on runit because i didn't trust sysvinit.  with
the advent of systemd, i think that vblade-persist would be better
implemented as a vblade-launch script and a vblade@.service systemd
template that invokes vblade-launch.  Then the standard systemctl
mechanisms could be used to control arbitrary vblade processes.

this would remove the dependency on runit, and would allow local
sysadmins to control persistent units like so:

      systemctl install vblade@eth0.2.3-dev-sda2.service

this would mean a systemd template file like (untested):

---------------
[Unit]
Description=vblade AOE exporter %i

[Service]
type=simple
ExecStart=/usr/bin/vblade-launch %i

[Install]
WantedBy=multi-user.target
---------------

It'd take a bit of thinking about how to handle mac address
limitations, and the decision about whether to place the symlink or
not, to bring this up to parity with the current implementation, but
then this work could be donated directly to the vblade upstream, and
we could leave it at that.

If someone wants to adopt vblade-persist, that would be fine with me.
If someone wants to take the systemd approach i describe above, i'd be
happy to ask for an RM: for vblade-persist as well.

      --dkg

--- End Message ---
--- Begin Message --- 
Version: 0.6-3+rm

Dear submitter,

as the package vblade-persist has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/921984

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

--- End Message ---
Reply to: