Bug#833721: ITP: python-aptly -- Aptly API client and CLI tooling

[Filip Pytloun]

Package: wnpp
Version: 0.7.7
Severity: wishlist
Owner: Filip Pytloun 

* Package name: python-aptly
  Version : 0.7.7
  Upstream Author : Filip Pytloun 
* URL : https://github.com/tcpcloud/python-aptly
* License : GPL-2
  Programming Lang: Python
  Description : Aptly API client and CLI tooling

Aptly REST API client and useful tooling
aptly-publisher is tooling for easier maintenance of complex repository 
management
workflows.


signature.asc
Description: Digital signature

Bug#833729: ITP: networking-sfc -- Service Function Chaining extension for OpenStack Neutron

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 

* Package name: networking-sfc
  Version : 1.0.0
* URL : http://github.com/openstack/networking-sfc
* License : Apache 2.0
  Programming Lang: Python
  Description : Service Function Chaining extension for OpenStack Neutron

networking-sfc provides API and implementation to support Service Function
Chaining in OpenStack Neutron.

Service Function Chaining is a mechanism for overriding the basic destination
based forwarding that is typical of IP networks. It is conceptually related
to Policy Based Routing in physical networks but it is typically thought of as
a Software Defined Networking technology. It is often used in conjunction with
security functions although it may be used for a broader range of features.
Fundamentally SFC is the ability to cause network packet flows to route through
a network via a path other than the one that would be chosen by routing table
lookups on the packet's destination IP address. It is most commonly used in
conjunction with Network Function Virtualization when recreating in a virtual
environment a series of network functions that would have traditionally been
implemented as a collection of physical network devices connected in series
by cables.

This package will be maintained under the pkg-openstack team.

Bug#833736: ITP: neutron-taas -- OpenStack virtual network service - Tap-as-a-Service extension

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 

* Package name: neutron-taas
* URL : https://github.com/openstack/tap-as-a-service
* License : Apache 2.0
  Programming Lang: Python
  Description : OpenStack virtual network service - Tap-as-a-Service 
extension

Tap-as-a-Service (TaaS) is an extension to the OpenStack network service 
(Neutron).
It provides remote port mirroring capability for tenant virtual networks.

Port mirroring involves sending a copy of packets entering and/or leaving one
port to another port, which is usually different from the original destinations
of the packets being mirrored.

This service has been primarily designed to help tenants (or the cloud 
administrator)
debug complex virtual networks and gain visibility into their VMs, by 
monitoring the
network traffic associated with them. TaaS honors tenant boundaries and its 
mirror
sessions are capable of spanning across multiple compute and network nodes. It 
serves
as an essential infrastructure component that can be utilized for supplying 
data to a
variety of network analytics and security applications (e.g. IDS).

Package will be maintained under the pkg-openstack team.

more GRs to come (Re: Current GRs clarification)

[Holger Levsen]

Hi Kurt,

thanks for these clarifications!

On Sun, Aug 07, 2016 at 11:06:03PM +0200, Debian Project Secretary - Kurt 
Roeckx wrote:
> GR about declassifying debian-private
> =
> 
> There are 2 options on the ballot:
> - Choice 1: Allow declassifying parts of debian-private
> - Choice 2: Further Discussion
> 
> If the first option wins, the GR of 2005 is repealed and replaced
> by this GR.  If the second option wins, nothing changes and the GR
> of 2005 will stay in effect.

I expressed my surprise about a missing third option ("depeal the GR
of 2005 and burry the idea of systematically declassifying
debian-private") on #debian-private and have learned there that this
seems to have been an oversight / others agree that there should have
been this third option.

So, I hereby announce that I'll propose another GR to "depeal the GR
of 2005 and burry the idea of systematically declassifying debian-private"
if *this* GR turns out to result in "further discussion".

(Because I think if choice 1 does *not* win, the project doesnt really
want further discussion but rather this idea to be burried for good.)

Obviously, if choice 1 does win, I will *not* propose a GR to overcome this.
But if choice 1 does *not* win, I don't think the projects want "further
discussion" but rather "choice 3".


If you reply, please respect the reply-to: headers.

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#833761: ITP: salt-formula-swift -- Salt formula for OpenStack Swift

[Filip Pytloun]

Package: wnpp
Version: 2016.8.1
Severity: wishlist
Owner: Filip Pytloun 

* Package name: salt-formula-swift
  Version : 2016.8.1
  Upstream Author : tcpcloud 
* URL : https://wiki.openstack.org/wiki/OpenStackSalt
* License : Apache-2.0
  Programming Lang: SaltStack
  Description : Salt formula for OpenStack Swift

Salt is a powerful remote execution manager that can be used to
administer servers in a fast and efficient way.

This SaltStack formula manages both installation and configuration of
OpenStack Nova.


signature.asc
Description: Digital signature

Bug#833765: ITP: networking-ovn -- OpenStack virtual network service - OVN mechanism driver

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 

* Package name: networking-ovn
  Version : 1.0.0~
* URL : https://github.com/openstack/networking-ovn
* License : Apache 2.0
  Programming Lang: Python
  Description : OpenStack virtual network service - OVN mechanism driver

OVN provides virtual networking for Open vSwitch and is a component of the Open
vSwitch project.  This project provides integration between OpenStack Neutron
and OVN.

This package will be maintained under the pkg-openstack team.

Bug#833793: ITP: telegram-purple -- Adds support for Telegram to libpurple

[Ben Wiederhake]

Package: wnpp
Severity: wishlist
Owner: Ben Wiederhake 

* Package name: telegram-purple
  Version : 1.3.0
  Upstream Author : Matthias Jentsch 
* URL : https://github.com/majn/telegram-purple
* License : GPL2+
  Programming Lang: C
  Description : Adds support for Telegram to libpurple

This provides a libpurple plugin that allows e.g. pidgin to
use Telegram (telegram.org) as a backend.

This package is relevant, because currently users would have to choose between:
- Not using Telegram at all
- Using the official Telegram client (which is considered annoying, because
users want to keep ONE im client with ALL accounts)
- Downloading, compiling, installing directly from source (which is annoying
because that's what the debian repo is for)

I personally use it, and several friends of mine. I participated in making it
ready for Debian (e.g. cleared a GPL-violation, cleaned up the build system).
I will continue to use and maintain this package, because I rely on being
able to be reachable via Telegram via Pidgin.

There are other packages (all in RFP state) that provide similar functionality:
- "tg", which is called upstream "telegram-cli", is a CLI for communicating
with telegram. This serves the need of those who EXCLUSIVELY use telegram. I
don't fall into this group.
- "telegram", which is a RFP of the official client. Same problem: This serves
the need of those who EXCLUSIVELY use telegram. I don't fall into this group.
- Note that this is a resurrection of #800771, as it timed out.

You might notice that tg (telegram-cli) and telegram-purple both use the same
basic library: libtgl ( https://github.com/vysheng/tgl )
It is not meaningful to ship that package separately as a "shared library"
(e.g.
"libtgl.so").  The rationale for this and other packaging choices can be
found in `debian/README.source`.

Just to reassure: upstream of telegram-purple (= Matthias Jentsch) is very
willing to see telegram-purple accepted in Debian.

Proposed maintainers:
- Ben Wiederhake (absolutely no experience in maintaining a Debian package)

If you intend to check out the source on GitHub, please notice that this
project makes use of git submodules *within* git submodules, and thus you
need to do "git clone --recursive https://github.com/majn/telegram-purple";

The current efforts of "Debianization" can be found at this branch:
https://github.com/BenWiederhake/telegram-purple/tree/debian-develop/

You might notice that 1.3.0 isn't released yet -- that's because it truely
isn't.  However, it's stable, and they/we are about to release, and I think
there's nothing essential missing in `debian/`, so I might be able to RFS
within a day after release of 1.3.0.

Regards,
Ben

Bug#833804: ITP: mkosi -- create legacy-free OS images

[Felipe Sateler]

Package: wnpp
Severity: wishlist
Owner: Felipe Sateler 

* Package name: mkosi
  Version : 1
  Upstream Author : Lennart Poettering
* URL : https://github.com/systemd/mkosi
* License : LGPL-2.1
  Programming Lang: Python3
  Description : create legacy-free OS images

 A fancy wrapper around "dnf --installroot", "debootstrap" and
 "pacstrap", that may generate disk images with a number of
 bells and whistles.

 Generated images are "legacy-free". This means only GPT disk
 labels (and no MBR disk labels) are supported, and only
 systemd based images may be generated. Moreover, for bootable
 images only EFI systems are supported (not plain MBR/BIOS).

I plan to maintain this within the pkg-systemd umbrella

Bug#833822: ITP: sagetex -- LaTeX package for Sage

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: sagetex
  Version : 3.0
  Upstream Author : Dan Drake 
* URL : https://github.com/dandrake/sagetex
* License : GPL-2+, CC-BY-SA-3.0
  Programming Lang: TeX, Python
  Description : LaTeX package for Sage


The SageTex LaTeX package allows you to embed code, results of computations,
and plots from Sage[Math] into LaTeX documents; Sage[Math] is a Computer
Algebra System (CAS) .