[Summary]
MIR Team conditional-Ack. Good packaging in general, but we need the steps below to be completed before being really ready for promotion:

@rafaeldtinoco - please update targetcli-fb
 - update targetcli-fb to 2.1.51
 - fix d/watch to detect the non *fb* versions
 - as usual work with Debian to have it there as well sooner or later
 - not sure but it might even need an epoch :-/
   $ dpkg --compare-versions 2.1.fb49 lt-nl 2.1.51 => NO
   But OTOH:
   UserWarning: The version specified ('2.1.fb49') is an invalid version
@rafaeldtinoco - please get Josh to subscribe to (all) these packages
 - we can drop that later, but that way we
   a) don't miss it later
   b) get a glimpse of the bug influx on these packages
@rafaeldtinoco - tests missing
Can we get some tests that will exercise targetcli-fb in this or another
package of this MIRs context?
@Rafael - once you are done with the above, please assign security to the targetcli-fb task

@security - please put it on your review queue, but only process it once we are
at version >=2.1.51 which @rafaeldtinoco will work on first.

[Duplication]
This is "Command shell for managing the Linux LIO kernel target" we don't have that in main yet.
TGT is no full alternative and to be replaced (tgt to be demoted) once we are ready to promote this.

[Dependencies]
OK:
- python3-rtslib-fb and python3-configshell-fb which are part of this MIR bug as well.
- The rest is in main already.
- No -dev/-debug/-doc packages with extra deps that would be auto-incldued that need exclusion later on promotion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
=> "viewing, editing, and saving the configuration of the kernel's target
   subsystem" does not have exploitable elements on their own.
   The security in this particular case is needed and done on the kernel side.
   I think as-is no security review would be needed.
   But going to 2.1.51 (see below) will introduce targetclid which then is:

Problem:
- does run a daemon as root
- does parse data formats

I don't think any of that will be critical as it is just parts of the former CLI
portion broken out to a daemon, but e.g. exploiting the daemon could get control
of LIO controlled credentials.
Therefore looking at what we will eventually have a security review (probably
quick) is requested.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (admin only)?
- no new python2 dependency
- uses dh_python

Problems:
- no Team subscriber yet, server-team please subscribe
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
  -> could we get some basic tests when working on 2.1.51 to at least cover
     and detect the most obvious issues)
     It might be ok to get the tests done in one of the packages here that
     would then use all the packages belonging to this "context".

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- Upstream update history is good
- promoting this does not seem to cause issues for MOTUs that so far maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using

Problems:
- Debian/Ubuntu update history is slow e.g. 2.1.fb49 was added ~1year after its release
- the current release is not packaged, d/watch doesn't detect the new versions
  so we miss 1.5y of updates which needs to be fixed.
  => https://github.com/open-iscsi/targetcli-fb/compare/v2.1.fb49...v2.1.51
- d/watch is present but missed non fb prefixed releases
@Rafael - I'd ask you to fix those things up

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (python)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid (needs very careful design (prefer systemd to set those for services))
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks (If this is a scope for the Unity Dash, does it honor the privacy settings?)