Bug#1068342: RFP: valkey -- Persistent key-value database with network interface (Redis fork)

[Guillem Jover]

Hi!

On Wed, 2024-04-03 at 12:29:44 -0400, Antoine Beaupre wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: Guillem Jover , "Chris Lamb" 
> 
> 
> * Package name: valkey
>   Version : 7.2.4
>   Upstream Contact: https://github.com/valkey-io
> * URL : https://github.com/valkey-io/valkey
> * License : BSD-3
>   Programming Lang: C
>   Description : Persistent key-value database with network interface 
> (Redis fork)
> 
> Valkey is a high-performance data structure server that primarily
> serves key/value workloads. It supports a wide range of native
> structures and an extensible plugin system for adding new data
> structures and access patterns.
> 
> 
> 
> "This project was forked from the open source Redis project right
> before the transition to their new source available licenses."
> 
> Valkey is one of many Redis forks out there, but it seems to me to be
> the most promising one, at least after reading this LWN article:
> 
> https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/

Yes, I initially had doubts about it because at the time it did not
even have a name, and thought that Redict might be the only viable
direct option. But before the article came up, and after checking a
bit more the context, my impression swapped, and I agree that this
feels more like the spiritual successor for Redis.

> For me, the plus sides:
> 
>  1. unchanged licence (while redict changed to LGPL)

I agree that license continuity is a plus for a project with an
established user base and ecosystem, and that the LGPL change could
be rather disruptive here.

>  2. has the backing of the Linux foundation

  2.1 apparently including Snapchat, so KeyDB might perhaps
  eventually be abandoned for this one (?)

>  3. exact same feature set as Redis before the fork (while KeyDB is
> lagging behind)

Although I'd qualify this, as it does not seem so clear cut, KeyDB has
a different set of features currently missing in Redis/Valkey, such
as active-active replication support (which we require at work), and
multi-threading (for a nice performance boost). It has indeed not
integrated the changes from Redis 7 (which we have not missed).

   4. has many of the old contributors, including previous core team
  members

> We use Redis at the Tor Project internnally, and we're looking for a
> smooth transition, drop-in replacement.

For a smooth migration from Redis 7, Valkey seems like the obvious
candidate indeed.

Thanks,
Guillem

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

[Guillem Jover]

Hi!

On Fri, 2024-03-22 at 12:35:47 +, Chris Lamb wrote:
> > I'm CCing Chris, who might perhaps be interested in replacing Redis with
> > KeyDB as its spiritual successor and taking this on? Or if not, at least
> > to perhaps potentially coordinate some kind of transition, even though
> > we've had issues migrating persistent DBs from newer Redis to KeyDB, so
> > that might be tricky or not feasible at all.
> 
> Thanks for including me here. I had not yet looked into potential
> Redis replacements nor the exact and precise details of the new
> license etc. and this activity around KeyDB feels like a good start.
> I thought I'd let the dust settle for a bit before making any
> decisions — perhaps the change even gets reversed (!), and no doubt
> there might be new alternatives that will fork the code immediately
> prior to the license change.

Yeah, fair enough.

> My personal and professional usage of Redis has dropped off in the
> past few years, so it would make more sense for me to help out in a
> team maintainership role, at least with respect to KeyDB.

Ack.

> However, I'd be interested in coordinating around some kind of
> Redis→KeyDB/something transition if need be.

For KeyDB, that would also depend on whether KeyDB adds Redis 7 support
or not I guess.

  https://github.com/Snapchat/KeyDB/issues/420

and if that does not materialize, a potential migration path via:

  https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311

In our, case we migrated from Redis 6 to KeyDB, so the above did not
really affect us.

> (Incidentally, why did your work switch to KeyDB?)

We did this several years ago, AFAIR mainly for its active-active
replication mode for our HA setup. The multi-threading was a nice
improvement too. And I cannot recall exactly, but I think at that
time Redis Inc was already going into a weird licensing path with
its other adjacent projects, so we might have taken that too as a
nice side effect to get away from.

Thanks,
Guillem

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

[Guillem Jover]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Chris Lamb , Sascha Steinbiss 

* Package name: keydb
  Version : 6.3.4
  Upstream Contact: https://github.com/Snapchat/KeyDB
* URL : https://keydb.dev/
* License : BSD-3-clause
  Programming Lang: C, C++
  Description : persistent key-value database with network interface

 keydb is a key-value database in a similar vein to memcache but the dataset
 is non-volatile. keydb additionally provides native support for atomically
 manipulating and querying data structures such as lists and sets.
 .
 The dataset is stored entirely in memory and periodically flushed to disk.



This project started as a fork from redis, for improved performance and
multi-threading support. We switched at work to it some time ago, and
had pending sending an RFP/ITP, but given the just announced license
change for redis to make it non-free [L], this seems more relevant now.
We've got the packaging bits around, which I'll try to send to this bug
report, but there's still some work that might be needed before an
upload, at least:

  - Unvendor more stuff (we have at least unvendored jemalloc and
rocksdb, but most of the rest need to go too).
  - Switch to use _keydb:_keydb as user and group (instead of
keydb:keydb).
  - Review and improve the maintscripts (as I think we initially based
our packaging on the upstream provided templates).

I'll try to do this during this week or next one, but if someone would
like to package this right ahead, I can speed this up.

I'm CCing Chris, who might perhaps be interested in replacing Redis with
KeyDB as its spiritual successor and taking this on? Or if not, at least
to perhaps potentially coordinate some kind of transition, even though
we've had issues migrating persistent DBs from newer Redis to KeyDB, so
that might be tricky or not feasible at all. I'm also CCing Sascha who
might be interested (given the keydb packaging repo in salsa). (I'm not
sure we are up for sole maintainership if no one takes this on, but
we'd be happy to give a hand in a team maintainership setting and that
might be an option for us if someone else is interested in driving this.)

[L] https://lwn.net/Articles/966133/

Thanks,
Guillem

Bug#960434: Bug#1026463: kanshi: Please ship kanshictl command and man page

[Guillem Jover]

Hi!

On Sat, 2024-01-13 at 15:36:09 +0100, Guillem Jover wrote:
> On Tue, 2020-05-12 at 09:43:04 -0400, Jason Francis wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Jason Francis 
> > 
> > * Package name: varlink
> >   Version : 19
> >   Upstream Author : Kay Sievers 
> > * URL : https://www.varlink.org/
> > * License : Apache-2.0
> >   Programming Lang: C
> >   Description : point-to-point IPC protocol and interface description
> > format
> > 
> > Varlink is an interface description format and protocol that aims to make
> > services accessible to both humans and machines in the simplest feasible 
> > way.
> > 
> > A varlink interface combines the classic UNIX command line options,
> > STDIN/OUT/ERROR text formats, man pages, service metadata and provides the
> > equivalent over a single file descriptor, a.k.a. “FD3”.
> > 
> > Varlink is plain-text, type-safe, discoverable, self-documenting, remotable,
> > testable, easy to debug. Varlink is accessible from any programming
> > environment.
> 
> > ---
> > 
> > Submission Notes:
> > Varlink is a small IPC protocol intended to be a very simple peer-to-peer
> > alternative to D-Bus. A minimal implementation has already been adopted by 
> > the
> > systemd project and integrated into their codebase; however I am submitting
> > this ITP in order to package the official C reference implementation that
> > includes a shared library and command line utility. Another package named
> > "kanshi" that I contribute to upstream is looking at using this library, 
> > and it
> > would be nice to have it ready in Debian for when a new version is 
> > published.
> > I'm not sure what package team this would fall under, but I've been testing
> > some Debian packaging already which is up on my github:
> > https://github.com/cyclopsian/libvarlink/tree/debian-19/debian
> 
> It looks like the upstream varlink project is dead or close to that.
> 
> The last commit on the libvarlink project is from 2 years ago, and
> I think there's been no apparent interaction in MRs and issues for a
> long time. The Linux kernel module for longer. And that looks similar
> for the other bindings, except for the Rust ones which have seen a
> few commits 6 months ago.
> 
> My memory was spotty about its popularity, so did some checking. It
> looks like podman gained varlink support but they then dropped it when
> varlink upstream told them they'd stop maintaining the project:
> 
>   https://podman.io/blogs/2020/12/11/remove-varlink-libpod-conf-notice
>   https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice
> 
> It looks like the main user, as noted above, is systemd, which imported
> or implemented minimal varlink code into their tree and do not use the
> external reference implementation at all.
> 
> Then also checked dependencies in Debian:
> 
>   - python3-varlink: 0 reverse depends
>   - golang-github-varlink-go-dev: 0 build-depends
> 
> A search for varlink.h across all Debian sources:
> 
>   https://codesearch.debian.net/search?q=varlink.h=1
> 
> shows only a handful of potential users. Searching instead of varlink
> gives way more hits, but I think the majority are unrelated, and instead
> are related to Java SWIG.
> 
> 
> The state of this upstream does not look very healthy, and from here
> it does not look like adding this to Debian might be entirely wise.
> For kanshi perhaps upstream should be looking into using something
> else, maybe Cap'n Proto <https://capnproto.org/>?

I ended up submitting a request upstream [I] to switch away from varlink,
which from my analysis above looks like a pretty dead project
upstream, but kanshi upstream mentioned not being interested and did
not give further insights about the varlink status or the effects of
depending on it.

  [I] <https://todo.sr.ht/~emersion/kanshi/104>

I don't think it would be wise to include varlink (as it is right now)
into Debian, and thus enabling support for it in kanshi does not seem
wise either to me, so I'll retract my request for this bug, thus
closing it now.

Thanks,
Guillem

Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

[Guillem Jover]

Hi!

On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Loren M. Lang 

> * Package name: golang-github-cheggaaa-pb
>   Version : 3.1.5-1
>   Upstream Author : Sergey Cherepanov
> * URL : https://github.com/cheggaaa/pb
> * License : BSD-3-clause
>   Programming Lang: Go
>   Description : Console progress bar for Golang

> This is a dependency for pwru which is in RFP and I plan to complete packaging
> shortly. pwru is an eBPF-based Linux kernel networking debugger.

This is already packaged as:

  golang-github-cheggaaa-pb.v3-dev
  golang-gopkg-cheggaaa-pb.v2-dev
  golang-gopkg-cheggaaa-pb.v1-dev

Thanks,
Guillem

Bug#960434: ITP: varlink -- point-to-point IPC protocol and interface description format

[Guillem Jover]

Hi!

[ I was asked to mentor someone to complete this ITP, which prompted
  me to look into its current state. ]

It seems Jason's mail bounces, so this ITP should at least be turned
into an RFP most probably, and even perhaps be closed, see below.

On Tue, 2020-05-12 at 09:43:04 -0400, Jason Francis wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jason Francis 
> 
> * Package name: varlink
>   Version : 19
>   Upstream Author : Kay Sievers 
> * URL : https://www.varlink.org/
> * License : Apache-2.0
>   Programming Lang: C
>   Description : point-to-point IPC protocol and interface description
> format
> 
> Varlink is an interface description format and protocol that aims to make
> services accessible to both humans and machines in the simplest feasible way.
> 
> A varlink interface combines the classic UNIX command line options,
> STDIN/OUT/ERROR text formats, man pages, service metadata and provides the
> equivalent over a single file descriptor, a.k.a. “FD3”.
> 
> Varlink is plain-text, type-safe, discoverable, self-documenting, remotable,
> testable, easy to debug. Varlink is accessible from any programming
> environment.

> ---
> 
> Submission Notes:
> Varlink is a small IPC protocol intended to be a very simple peer-to-peer
> alternative to D-Bus. A minimal implementation has already been adopted by the
> systemd project and integrated into their codebase; however I am submitting
> this ITP in order to package the official C reference implementation that
> includes a shared library and command line utility. Another package named
> "kanshi" that I contribute to upstream is looking at using this library, and 
> it
> would be nice to have it ready in Debian for when a new version is published.
> I'm not sure what package team this would fall under, but I've been testing
> some Debian packaging already which is up on my github:
> https://github.com/cyclopsian/libvarlink/tree/debian-19/debian

It looks like the upstream varlink project is dead or close to that.

The last commit on the libvarlink project is from 2 years ago, and
I think there's been no apparent interaction in MRs and issues for a
long time. The Linux kernel module for longer. And that looks similar
for the other bindings, except for the Rust ones which have seen a
few commits 6 months ago.

My memory was spotty about its popularity, so did some checking. It
looks like podman gained varlink support but they then dropped it when
varlink upstream told them they'd stop maintaining the project:

  https://podman.io/blogs/2020/12/11/remove-varlink-libpod-conf-notice
  https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice

It looks like the main user, as noted above, is systemd, which imported
or implemented minimal varlink code into their tree and do not use the
external reference implementation at all.

Then also checked dependencies in Debian:

  - python3-varlink: 0 reverse depends
  - golang-github-varlink-go-dev: 0 build-depends

A search for varlink.h across all Debian sources:

  https://codesearch.debian.net/search?q=varlink.h=1

shows only a handful of potential users. Searching instead of varlink
gives way more hits, but I think the majority are unrelated, and instead
are related to Java SWIG.


The state of this upstream does not look very healthy, and from here
it does not look like adding this to Debian might be entirely wise.
For kanshi perhaps upstream should be looking into using something
else, maybe Cap'n Proto ?

Thanks,
Guillem

Bug#1002056: Fedora plans to transition to Zlib-ng

[Guillem Jover]

Hi!

On Wed, 2023-10-25 at 14:13:54 -0300, Nelson A. de Oliveira wrote:
> JFTR, Fedora is planning to transition to Zlib-ng
> 
> https://fedoraproject.org/wiki/Changes/ZlibNGTransition

Ah, thanks! I had in my mind getting back to this ITP, given that the
zlib-ng project has continued to gain traction and seems to have
consolidated most of the other forks around it.

So I'll draft another mail to Mark and probably to debian-devel to
discuss this.

Thanks,
Guillem

Bug#389591: ITP: freeswitch -- Modular Media Switching Software Library and Soft-Switch Application

[Guillem Jover]

Hi!

I did a superficial license review for the upstream code and noticed
multiple issues, for which I've filed a bug report upstream. As it is
this does not look like it could be distributed in Debian.

  https://github.com/signalwire/freeswitch/issues/2092

Thanks,
Guillem

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[Guillem Jover]

Hi!

On Sat, 2023-03-25 at 21:24:44 +0100, David Heidelberg wrote:
> I see you recently pushed some code into git, do you plan to push the code
> also into Debian itself?

Given that it conflicts with the zlib package, and I'm not sure it
makes sense to upload just the zlib-ng specific library without the
compatibility shims, I'm currently not planning on doing so, no. But
I should probably discuss this further with Mark Brown.

Thanks,
Guillem

Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Guillem Jover]

Hi!

On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote:
> Package: wnpp
> Version: 1.79
> Severity: wishlist
> Owner: Juri Grabowski 
> X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@jugra.de

> * Package name: distribution-gpg-keys
>   Version : 1.7.9
>   Upstream Author : Miroslav Suchý 
> * URL : https://github.com/xsuchy/distribution-gpg-keys/
> * License : CC0-1.0
>   Programming Lang: data
>   Description : GPG keys by various Linux distributions
> 
> used by various Linux distributions to sign packages.
> 
> needed by mock/3.5 and I need a sponsor for this package. See current 
> packaging in
> https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys
> After I know ITP bug number I upload this source package to
> https://mentors.debian.net/package/distribution-gpg-keys/

The project name talks about gpg keys, but those are really OpenPGP
keys (or even better, certificates). I've asked upstream to rename the
project to avoid this common confusion. So you might want to wait until
that's settled to avoid multiple trips over NEW.

  

(If this project is also intended to only cover RPM-based distributions,
as Adam brought up, you might want to further ask them to make that clear
from the project name, say rpm-distribution-openpgp-keys or similar. But
in any case regardless of the intended target use, it still seems like a
very generic name which can be easily confused for a package that would
be needed for Debian, or derivatives.)

Thanks,
Guillem

Bug#1020698: O: dlocate -- fast alternative to dpkg -L and dpkg -S

[Guillem Jover]

Hi!

[ Sorry, should have CCed Craig, doing that now. ]

On Fri, 2022-09-30 at 04:07:05 +0200, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2022-09-25 at 16:19:08 +0200, Tobias Frost wrote:
> > Package: wnpp
> > 
> > The current maintainer of dlocate, Craig Sanders ,
> > is no longer maintaining this packages.
> > 
> > Maintaining a package requires time and skills. Please only adopt this
> > package if you will have enough time and attention to work on it.
> > 
> > If you want to be the new maintainer, please see
> > https://www.debian.org/devel/wnpp/#howto-o for detailed
> > instructions how to adopt a package properly.
> 
> Hmm, if this is really unmaintained now, although given that this is a
> native package it is not clear to me, then given the relationship and
> namespace usage, I think this would fit nicely within the dpkg suite.
> So I'm willing to take this one if so.

Just to clarify, I'd would only ever consider taking this on, if the
upstream status is also really "unmaintained".

Thanks,
Guillem

Bug#1020698: O: dlocate -- fast alternative to dpkg -L and dpkg -S

[Guillem Jover]

Hi!

On Sun, 2022-09-25 at 16:19:08 +0200, Tobias Frost wrote:
> Package: wnpp
> 
> The current maintainer of dlocate, Craig Sanders ,
> is no longer maintaining this packages.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
> 
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.

Hmm, if this is really unmaintained now, although given that this is a
native package it is not clear to me, then given the relationship and
namespace usage, I think this would fit nicely within the dpkg suite.
So I'm willing to take this one if so.

Thanks,
Guillem

Bug#1013992: ITP: session-migration -- tool to migrate in user session settings

[Guillem Jover]

On Tue, 2022-06-28 at 21:51:44 -0400, Jeremy Bicha wrote:
> On Tue, Jun 28, 2022 at 8:07 PM Guillem Jover  wrote:
> > > Package: session-migration
> > > Description: Tool to migrate in user session settings
> > >  This tool is used to migrate in session user data when a program is 
> > > evolving
> > >  its configuration, or needing to have files moved and so on.
> > >  .
> > >  This program is generally autostarted at the very beginning of the 
> > > session
> > >  and integrates caching capability.
> >
> > This looks like an extremely generic name for such tool and package,
> > when it appears to be restricted to gsettings session data only?
> 
> It is not restricted to gsettings although gsettings is a good use case for 
> it.
> 
> Here's an example where it's used for something else:
> https://salsa.debian.org/gnome-team/gnome-boxes/-/commit/b536a968eb192
> 
> It would be nice if the upstream developers would handle user session
> migrations tasks themselves, but they often don't.

Ah thanks, looking into it, it seems more generic indeed.

> > > Package: dh-migrations
> > > Provides: dh-sequence-migrations
> > > Description: debhelper extension for session-migration support
> > >  This package provides a debhelper extension to perform session migration
> > >  operations on the installed packages.
> >
> > This also seems extremely generic. Migrations could refer to anything,
> > from databases, to any other data source. Something like
> > dh-gsettings-migrations seems like would be way better?
> 
> Despite being around for a decade, it looks like it's only used by
> about 6 current Ubuntu source packages so a rename is doable if
> needed. I think I wouldn't even need a transitional package since we'd
> rebuild all those Ubuntu packages which would get them the properly
> named dependency.
> 
> Here's a suggestion:
> user-session-migration
> dh-migrate-user-session Providing dh-sequence-migrate-user-session

Personally I'd perhaps try to keep both names consistent, also
the name you propose for the dh helper looks as if it would be
performing the migration itself which can be misleading, so perhaps
something like dh-user-session-migration would be better? In any case
I'd take either (or similar variants) over dh-migrations. :)

Thanks,
Guillem

Bug#1013992: ITP: session-migration -- tool to migrate in user session settings

[Guillem Jover]

Hi!

On Tue, 2022-06-28 at 11:02:29 -0400, Jeremy Bicha wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org,
> pkg-ayatana-de...@lists.alioth.debian.org
> Owner: jeremy.bi...@canonical.com

> Package Name: session-migration
> Version: 0.3.7
> Upstream Author: Canonical
> License: LGPL-3+
> Programming Lang: Perl and C
> 
> Package: session-migration
> Description: Tool to migrate in user session settings
>  This tool is used to migrate in session user data when a program is evolving
>  its configuration, or needing to have files moved and so on.
>  .
>  This program is generally autostarted at the very beginning of the session
>  and integrates caching capability.

This looks like an extremely generic name for such tool and package,
when it appears to be restricted to gsettings session data only?

> Package: dh-migrations
> Provides: dh-sequence-migrations
> Description: debhelper extension for session-migration support
>  This package provides a debhelper extension to perform session migration
>  operations on the installed packages.

This also seems extremely generic. Migrations could refer to anything,
from databases, to any other data source. Something like
dh-gsettings-migrations seems like would be way better?

Thanks,
Guillem

Bug#1008304: ITP: http-nio -- http/s file system provider for Java NIO.2

[Guillem Jover]

Hi!

On Sat, 2022-03-26 at 14:59:17 +0100, Pierre Gruet wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian-med team 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org
> 
> * Package name: http-nio
>   Version : 0.1.0
>   Upstream Author : Daniel Gomez-Sanchez
> * URL : https://github.com/lbergelson/http-nio
> * License : BSD-3-Clause
>   Programming Lang: Java
>   Description : http/s file system provider for Java NIO.2
> 
> This package provides a http or https file system that can be used in
> conjunction with Java NIO.2. This lightweight library provides a few classes
> related to file systems and paths.
> 
> It is provided by the developers of gatk, which is a long-term packaging 
> target
> of Debian-med team. I am packaging it as a reverse dependency of gatk.
> For this reason, it will be team-maintained inside Debian-med team.

The http-nio name seems rather generic to be used as either source or
binary package name. Could you namespace it? I don't see a very clear
naming convention in the archive for Java packages, but then I have not
checked the java-policy, TBH. What I see is either -jave or
lib-java, either would work here.

Thanks,
Guillem

Bug#1004927: ITP: libtree -- ldd as a tree

[Guillem Jover]

Hi!

On Thu, 2022-02-03 at 19:31:20 +0100, Gürkan Myczko wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gürkan Myczko 
> X-Debbugs-Cc: debian-de...@lists.debian.org

Hmm, thought I had replied already, now that I just saw this in NEW.

> * Package name: libtree
>   Version : 3.0.2
>   Upstream Authors: Harmen Stoppels
>   URL : https://github.com/haampie/libtree
> * License : MIT
>   Description : ldd as a tree
>  This is tool like ldd with these features:
>  - turns ldd into a tree
>  - explains why shared libraries are found and why not

The name seems rather confusing, I'd assume this is a library
providing some kind of tree structure support or similar.

Could upstream perhaps rename this to something like lddtree or
similar?

Thanks,
Guillem

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[Guillem Jover]

On Mon, 2021-12-20 at 23:15:07 -0500, nick black wrote:
> not that i expect you to have run extensive benchmarks or
> anything, but how do you feel this compares to libdeflate?

I don't think it matters, because libdeflate does not support a
streaming API anyway, so it's of no use in many situations where
large files or streaming content needs to be dealt with. It also
does not provide a compatible zlib API, which means it cannot be
easily migrated to.

> the few comparisons i've seen suggest that they are (or at least
> were) pretty much a wash, performance-wise.

I think when I first noticed libdeflate being uploaded to Debian, I
took a look to also play with it for dpkg, but the above problems
meant that never got anywhere. From the benchmarks I've seen
libdeflate might be a bit faster, but then it would require tons more
memory to handle equivalent inputs and outputs.

The reasons I found the zlib-ng alternative interesting were because:

 - the Intel fork is not going to be adding non-Intel optimizations,
 - the Cloudflare fork does not look very lively,
 - the zlib upstream does not look very active, and apparently outright
   refuses contributions to the main code, and only accepts them into
   its contrib/ directory,

OTOH the zlib-ng looks very lively, accepts contributions, has had its
code modernized and cleaned up, and seems to be performing rather well
in comparison on multiple architectures.

Thanks,
Guillem

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 
X-Debbugs-Cc: debian-de...@lists.debian.org, Mark Brown 

* Package name: zlib-ng
  Version : 2.0.5
  Upstream Author : zlib-ng Team
* URL : http://github.com/zlib-ng/zlib-ng
* License : Zlib, Zlib-RFC, CC-BY-3.0, CC-BY-4.0, Public-Domain
  Programming Lang: C
  Description : optimized zlib compression library

 zlib-ng is a fork of the zlib library implementing the deflate compression
 method found in gzip and PKZIP.
 .
 It includes and consolidates many optimizations found in alternative forks,
 that have not been merged in the official zlib library.


I just discovered this project, and started packaging [P] it to be able
to play with a dpkg branch switching its zlib support to zlib-ng. The
speed up is quite significant, for example when packing the 0ad-data,
on my system it takes 5m50s~ with zlib and 4m30s~ with zlib-ng.

  [P] https://git.hadrons.org/cgit/wip/debian/pkgs/zlib-ng.git/

The project has a compat mode which generates API "compatible" zlib
replacement libraries, but unfortunately it is stated not to guarantee
to be ABI compatible, so no compat packages or similar could be
produced right now as that could potentially break other packages. I've
filed a report [S] upstream to request a more usable shim instead.

  [S] <https://github.com/zlib-ng/zlib-ng/issues/1081>


I'm still pondering whether to upload this, although the packing is
already done, but w/o the above mentioned shim its utility seems
restricted as most upstream projects use it via its compat mode,
instead of with its native API. But if that happens, I think it would
make sense to upload, as it's currently being embedded in several
upstream projects and even if dpkg would not switch to it, it would
still help with removing embedded code copies, and speeding up other
packages. Or make other RPFs such as #901490 (an alternative fork)
unnecessary.

Thanks,
Guillem

Bug#998039: ITP: makedeb -- The modern packaging tool for Debian archives.

[Guillem Jover]

[ Sorry, have not seen this up to now as the Debian BTS does not
  automatically CC people, that needs to be done explicitly. ]

Hi!

On Thu, 2021-11-04 at 08:44:57 -0700, LEO PUVILLAND wrote:
> What do you mean by hardcoded dependencies?

AFAICS with makedeb you hardcode f.ex. shared libraries in the
dependencies such as in:

  https://mpr.hunterwittenborn.com/cgit/aur.git/tree/PKGBUILD?h=polybar#n10

instead of both inferring the package name the libraries used come
from, and retrieving the correct versioned dependency information from
the shlibs and/or symbols files. (See the man pages for dpkg-shlibdeps,
deb-shlibs, deb-symbols and deb-src-symbols).

This means these can end up from encoding incorrect dependency
relationships that can cause linker errors, to segfaults due to ABI
requirements not fulfilled. Or simply require mass manual updates when
the SONAME is bumped but the API is preserved, which would otherwise
only require a rebuild.

Many of the debhelper tooling contains code implementing policies and
integration that is expected from packages that are installed on Debian
systems.

> > This also implies much
> > of the current automatic handling found in, say, debhelper and related
> > tools is skipped, which does not look would make it easier to generate
> > properly integrated packages.
> 
> makedeb doesn't use the native debian format and I believe that's a design
> choice, instead it uses the alternate PKGBUILD format, inspired by Arch
> Linux. I looked at the issues you mentioned and I can see your point.
> However, isn't one of the core principles of Linux freedom of choice? This
> is simply another way to package for Debian.

Sure, I understand that, and can see the appeal for some people coming
from the Arch Linux world. But that still will just not produce fully
and correctly integrated Debian packages.

I don't think freedom of choice is a core principles of Linux (the
kernel? :), nor the FOSS movement. People might want that, and that's
fair, but we should never forget that more choice can also bring more
confusion, worse user experience, etc. In this case I think upstream
should clearly note all limitations with this approach, and start by
not stating this is “the modern packaging tool for Debian”. :)

Including (currently) this in Debian, to me gives the impression this
packaging method will give results of similar quality and integration
as packaging with native tools, which seems undesirable, TBH.

Thanks,
Guillem

Bug#998039: ITP: makedeb -- The modern packaging tool for Debian archives.

[Guillem Jover]

Hi!

On Thu, 2021-10-28 at 15:02:19 -0700, Leo Puvilland wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Leo Puvilland 
> 
> * Package name: makedeb
>   Version : 7.1.2+bugfix1
>   Upstream Author : Hunter Wittenborn 
> * URL : https://makedeb.hunterwittenborn.com
> * License : GPLv2
>   Programming Lang: Bash
>   Description : The modern packaging tool for Debian archives.

Hmm, I think I take issue with this description. :)

While I can agree there's much that can be changed in dpkg and
related tooling such as debhelper to improve packaging workflows and
make this a more integrated and easy thing to approach for new people,
I'm not seeing how makedeb is neither "The" nor "modern" tool for
this. I feel it suffers from pretty much the same problems as fpm
(see  or
).

> makedeb is a packaging tool for Debian-based systems that aims to be
> simple and easy to use, whilst still remaining just as powerful as
> standard Debian tooling.

I'm afraid, simple here implies potentially incorrect (see the comments
on the links about ignoring dependency information from shlibs/symbols
files f.ex), checking the upstream repo I see dependencies are being
hardcoded, which seem even worse than I'd expect. This also implies much
of the current automatic handling found in, say, debhelper and related
tools is skipped, which does not look would make it easier to generate
properly integrated packages.

> makedeb uses a packaging format that's aiming to be simpler and easier
> to get a hold of than standard Debian packaging, so adding this
> program would help more users begin packaging for Debian.

I think this makes the packaging experience even more confusing, as
these people might still need to have to deal with proper Debian
packaging anyway.

Thanks,
Guillem

Bug#992539: ITP: which-gnu -- Utility to show the full path of commands

[Guillem Jover]

Hi!

On Thu, 2021-08-19 at 16:50:48 -0400, Boyuan Yang wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Boyuan Yang 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: which-gnu
>   Version : 2.21
>   Upstream Author : Carlo Wood 
> * URL : https://savannah.gnu.org/projects/which
> * License : GPL-3+
>   Programming Lang: C
>   Description : Utility to show the full path of commands
> 
>  This package provides GNU implementation of which command.
>  This tool provides the functionality to show the full path
>  of commands.
> 
> This package comes as an alternative to the /usr/bin/which command as
> previously provided by debianutils. Please also refer to
> https://lists.debian.org/debian-devel/2021/08/msg00204.html for a background.
> Also check https://salsa.debian.org/debian/which-gnu/ for the git packaging
> repo.
> 
> My name is on lowNMU list so package co-maintenance is welcome. Feel free to
> let me know if you also would like to be listed as package uploader.

Could you instead namespace the program with a gnu or gnu- prefix? To
follow existing practice in the archive for GNU projects?

I'd also name both source and binary package as the same, to leave
room for alternative implementations.

Thanks,
Guillem

Bug#989068: ITP: object-cloner -- Java Object cloning library with extensible strategies

[Guillem Jover]

Hi!

On Mon, 2021-05-24 at 20:08:57 -0400, James Valleroy wrote:
> Package: wnpp
> Severity: wishlist
> Owner: James Valleroy 
> X-Debbugs-Cc: debian-de...@lists.debian.org, jvalle...@mailbox.org
> 
> * Package name: object-cloner
>   Version : 0.2
>   Upstream Author : Kamran Zafar 
> * URL : https://github.com/kamranzafar/object-cloner
> * License : Apache-2.0
>   Programming Lang: Java
>   Description : Java Object cloning library with extensible strategies
> 
> Java Object cloning library. Supports extensible shallow and deep object 
> cloning strategies.
> 
> This is a dependency of jcl-core, which is needed for jitsi-videobridge 
> (#757769).

The source package seems overly generic, could you namespace it
please? Say name it to what I assume might end up being the binary
name «libobject-cloner-java»?

Thanks,
Guillem

Bug#988689: ITP: 7zip -- 7-Zip file archiver

[Guillem Jover]

Hi!

On Tue, 2021-05-18 at 09:07:17 +0900, YOKOTA Hiroshi wrote:
> Package: wnpp
> Severity: wishlist
> Owner: YOKOTA Hiroshi 
> X-Debbugs-Cc: debian-de...@lists.debian.org, yokota.h...@gmail.com
> 
> * Package name: 7zip
>   Version : 21.02
>   Upstream Author : Igor Pavlov
> * URL : https://www.7-zip.org/
> * License : LGPL with "unRAR license restriction" (
> https://www.7-zip.org/license.txt )
>   Programming Lang: C, C++, Asm
>   Description : 7-Zip file archiver
> 
> 7-Zip is a file archiver with a high compression ratio.
[… description …]

> note: "p7zip-full" package provides full-featured, but older 7-Zip archiver.
>   This "7zip" package provides stand-alone style archiver only, but
>   newer 7-Zip archiver.
>   "7zip" package is in "non-free" section because "unRAR" code is not
>   compatible with DFSG.
> 
> Current packaging state is held on https://salsa.debian.org/yokota/7zip .

It looks like we already have the 7-Zip unrar code split on its own
source package in non-free (p7zip-rar). Have you contacted the p7zip
maintainer (CCed) to check what might be blocking updating the packages
to a newer upstream version, instead of duplicating them? Perhaps you
could collaborate on that instead?

Thanks,
Guillem

Bug#986997: O: netkit-telnet -- basic telnet client

[Guillem Jover]

Hi!

On Thu, 2021-04-15 at 21:18:03 +0200, Simon Josefsson wrote:
> Chris Hofstaedtler  writes:
> > * Simon Josefsson  [210415 19:06]:
> >> Hi!  Upstream is not maintained either -- at least the download URL in
> >> netkit-telnet's debian/copyright file does not work.  How about dropping
> >> netkit-telnet from Debian?
> >
> > In #982253 I've expressed that I for one would find that to be a
> > good idea. But quite clearly it is work that needs to be a) done and
> > b) well coordinated.
> 
> I'm happy to work on replacing netkit-based tools with inetutils once
> bullseye is out, although Guillem have to agree since he maintains
> inetutils in Debian.  If something needs to be modified in inetutils to
> be more compatible with netkit, I will help to arrange that.

That'd be great, thanks! I think I've mentioned before, but in any
case getting #945861 fixed would be nice, as I took a look but run
out of time trying to figure out what was the problem.

Adding TLS support to both inetutils telnet and telnetd would also be
great, even though inetutils versions support Kerberos, but I think
probably more people might use TLS enabled telnet than Kerberos
enabled telnet. This might make it possible to also get rid of
telnet-ssl and telnetd-ssl.

> Starting
> with telnet+telnetd seems like a good idea.

I've not checked if there are any differences in the options,
otherwise I'd be fine with adding a transitional package, to smooth
the upgrade, and then simply just provide telnet and telnetd (in
addition to telnet-client and telnet-server) virtual packages.

> Btw, the suggestion to symlink telnet to netcat is not a good one:
> telnet is a complex protocol, netcat doesn't support any of it as far as
> I know.

I agree.

Thanks,
Guillem

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Guillem Jover]

Hi!

On Sun, 2021-03-21 at 14:03:32 +0100, Stephen Kitt wrote:
> Control: retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
> library wrapping SDL 2.0
> Control: owner -1 !
> 
> On Sun, 21 Mar 2021 11:17:32 +, Simon McVittie  wrote:
> > On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> > > I've recently retried switching to Wayland and I think I'm sticking
> > > with it. But while checking for toolkits support, noticed that SDL 1.2
> > > does not have native Wayland support, but SDL 2.0 does.  
> > 
> > Note that SDL 2.0 currently defaults to using X11 if available, and will
> > currently only use Wayland if X11 is unavailable, so in environments where
> > Xwayland is either always run (such as GNOME 3.38) or started automatically
> > on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
> > I think typical desktop environments like GNOME and KDE Plasma are
> > likely to want Xwayland available by default for quite a long time,
> > even if it's only started on-demand.

Sure, in my case sway, but all the same. My goal is to be able to
disable Xwayland completely though. :)

> > You can override this with with environment variable
> > SDL_VIDEODRIVER=wayland.

Yes, the problem though is that this cannot be set unconditionally in
one's environment, as any SDL-1 program will then fail to start
completely (some might even segfault if they are not checking the SDL
initialization function return codes, as I found out with hex-a-hop,
which should now be fixed upstream :).

> Right, I’ll make sure to document this in the package.

Please, document that setting this unconditionally is currently not a
good idea.

> > On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> > > As seen in [1] regarding the headers, sdl12-compat isn't a full
> > > replacement yet.
> > > 
> > > It could work for pure binary-compatibility but you can't build anything
> > > against it yet so it should be a Provide+Replace rather than something
> > > like a newer version.
> > > 
> > > 1: https://github.com/libsdl-org/sdl12-compat/issues/34  
> > 
> > Yes, I'd come to that conclusion too.
> 
> Yup, for the time being it’s really only a runtime replacement, it’s not
> ready as a build-time SDL2 shim for SDL1.2 projects.

Right, sorry should have made this more clear in the RFP.

There was also <https://github.com/MrAlert/sdlcl>, which seems might
have been more complete, but given that it does not seem to be active
anymore and not maintained by upstream SDL, it was not worth pursuing.

Thanks,
Guillem

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Guillem Jover]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-sdl-maintain...@lists.alioth.debian.org, 
debian-devel-ga...@lists.debian.org

* Package name: libsdl1.2-compat
  Version : 0.0~git
  Upstream Author : Ryan C. Gordon 
* URL : https://github.com/libsdl-org/sdl12-compat
* License : zlib/libpng
  Programming Lang: C
  Description : SDL 1.2 binary compatibility library wrapping SDL 2.0

This code is a compatibility layer; it provides a binary-compatible API for
programs written against SDL 1.2, but it uses SDL 2.0 behind the scenes. If
you are writing new code, please target SDL 2.0 directly and do not use this
layer.



I've recently retried switching to Wayland and I think I'm sticking
with it. But while checking for toolkits support, noticed that SDL 1.2
does not have native Wayland support, but SDL 2.0 does.

Unfortunately we have quite many packages still using SDL 1.2, and while
I think I'll start porting them one by one (when time permits), it still
would be nice to get this wrapper packaged so that we can get immediate
results and can stop depending on Xwayland for most of the packages in
Debian.

Thanks,
Guillem

Bug#977164: RFP: golang-github-victoriametrics-metricsql -- standalone PromQL and MetricsQL parser

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-victoriametrics-metricsql
  Version : 0.8.0-1
  Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/metricsql
* License : Apache-2.0
  Programming Lang: Go
  Description : standalone PromQL and MetricsQL parser (library)

 The package metricsql implements the MetricsQL
 (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/MetricsQL)
 and PromQL
 (https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085)
 parsers in Go.

This is a required dependency for victoria-metrics.

I've got the tested and working packaging which I'll push into salsa once
this bug has been filed.

Thanks,
Guillem

Bug#974935: RFP: golang-github-ncabatoff-fakescraper -- scrape Prometheus metrics from inside the app

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-ncabatoff-fakescraper
  Version : 0.0~git20201102.4b37ba6-1
  Upstream Author : Nick Cabatoff
* URL : https://github.com/ncabatoff/fakescraper
* License : https://github.com/ncabatoff/fakescraper/issues/2
  Programming Lang: Go
  Description : scrape Prometheus metrics from inside the app

 Intended when writing Prometheus exporters and wanting to test them
 from the command line. This avoids needing to start the daemon, run curl
 to fetch the metrics, then kill it.


This is a dependency for prometheus-process-exporter, which was previously
vendored and got unvendored upstream. I've got the packaging which I'll
provide as an MR once this bug has been filed.

The upstream repo has no license, and I've submitted an issue to get
that clarified, but that is not so different from the current situation
where that package is vendored and it does not contain an explicit
license anyway. Of course I don't expect this to be uploaded until that
issue has been resolved.

Thanks,
Guillem

Bug#974934: RFP: golang-github-ncabatoff-go-seq -- sequence Go values to allow sorting them

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-ncabatoff-go-seq
  Version : 0.0~git20180805.b08ef85-1
  Upstream Author : Nick Cabatoff
* URL : https://github.com/ncabatoff/go-seq
* License : Expat
  Programming Lang: Go
  Description : sequence Go values to allow sorting them

 This package is intended to allow ordering (most) values via reflection,
 much like go-cmp allows comparing values for equality.
 .
 This is helpful when trying to write Less() methods for sorting
 structures.
 .
 Notable unsupported types include the builtin complex type, channels,
 functions, and maps with non-string keys. Pointers can be ordered if
 their underlying types can be ordered.


This is a dependency for prometheus-process-exporter, which was previously
vendored and got unvendored upstream. I've got the packaging which I'll
provide as an MR once this bug has been filed.

Thanks,
Guillem

Bug#969781: RFP: libtoml-tiny-perl -- minimal, pure perl TOML parser and serializer

[Guillem Jover]

Hi!

On Tue, 2020-09-08 at 17:34:28 +0200, gregor herrmann wrote:
> On Tue, 08 Sep 2020 03:19:36 +0200, Guillem Jover wrote:
> > Attached a working and tested packaging, where only the ITP bug number
> > needs to be filled in the debian/changelog, Maintainer changed, and
> > Vcs fields added if appropriate.
> 
> Thanks!

Well, thank you for taking maintainership and uploading!

> libtoml-tiny-perl is in the NEW queue now.

Perfect, thanks! BTW upstream fixed the dependency problem for which
I included a patch, I think in a better way, and released a new
version. :)

Also, I guess you might not have removed me as maintainer out of
courtesy? :) If so, I think for now I'd prefer to not be listed, as
I'm afraid I've got too much on my plate, although I would not mind
lending a hand for specific issues or similar if needed!

Thanks,
Guillem

Bug#969781: RFP: libtoml-tiny-perl -- minimal, pure perl TOML parser and serializer

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libtoml-tiny-perl
  Version : 0.09
  Upstream Author : Jeff Ober 
* URL : https://metacpan.org/release/TOML-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : minimal, pure perl TOML parser and serializer

 TOML::Tiny implements a pure-perl parser and generator for the
 TOML (https://github.com/toml-lang/toml) data format. It currently conforms
 to TOML v5 (with a few caveats) with support for more recent changes in
 pursuit of v6.
 .
 TOML::Tiny strives to maintain an interface compatible to the TOML and
 TOML::Parser modules, and could even be used to override $TOML::Parser.


This package contains both an encoder and decoder that can handle new
TOML formats, in contrast with the existing TOML and TOML::Parser in
the archive that cannot handle encoding decoded data for new formats.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and
Vcs fields added if appropriate. I've also included a patch to make
the heavy dependency on DateTime::Format::RFC3339 a Suggests, as that
ended up pulling tons of packages and is only needed when passing data
with such objects (which I've sent upstream as
).

Thanks,
Guillem


libtoml-tiny-perl_0.09-1.debian.tar.xz
Description: application/xz

Bug#950903: ITP: liburing -- Linux kernel io_uring access library

[Guillem Jover]

Hi!

On Tue, 2020-04-21 at 12:39:46 +0300, Michael Tokarev wrote:
> On Fri, 10 Apr 2020 19:27:27 +0200 Guillem Jover  wrote:
> 
> > The packaging is ready, but there were some issues that needed fixed
> > upstream. The blocking one is about getting the licensing situation
> > clarified:
> > 
> >   <https://github.com/axboe/liburing/pull/104>
> > 
> > Once that's solved, I'll upload.

> New qemu (5.0) will be able to work with liburing.
> 
> How things are on the packaging-it front?
> I even packaged it by my own already, but later
> remembered to take a look at wnpp and found your
> work here.
> 
> The above pull request with license clarification
> has been accepted.

Yeah, I also asked for a new upstream release and once that was done I
uploaded it. It's been sitting in NEW now for some days. :)

(Hmm I thought there was a bot marking ITPs sitting in NEW as pending.)

Thanks,
Guillem

Bug#950903: ITP: liburing -- Linux kernel io_uring access library

[Guillem Jover]

Hi!

On Sat, 2020-02-08 at 01:01:01 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Guillem Jover 
> 
> * Package name: liburing
>   Version : 0.4
>   Upstream Author : Jens Axboe 
> * URL : https://git.kernel.dk/cgit/liburing/
> * License : LGPL and MIT/X
>   Programming Lang: C
>   Description : Linux kernel io_uring access library
> 
>  liburing provides helpers to setup and teardown io_uring instances,
>  and also a simplified interface for applications that don't need (or
>  want) to deal with the full kernel side implementation.
> 
> 
> The liburing library is supposed so supercede the libaio library which
> I maintain too, so it makes sense to handle both. :)

The packaging is ready, but there were some issues that needed fixed
upstream. The blocking one is about getting the licensing situation
clarified:

  <https://github.com/axboe/liburing/pull/104>

Once that's solved, I'll upload.

Thanks,
Guillem

Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics

[Guillem Jover]

Hi!

On Thu, 2020-03-19 at 18:30:17 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Tags: patch
> 
> * Package name: prometheus-redis-exporter
>   Version : 1.4.0

Version : 1.5.2

>   Upstream Author : Oliver
> * URL : https://github.com/oliver006/redis_exporter
> * License : MIT
>   Programming Lang: Go
>   Description : Prometheus exporter for Redis metrics
> 
>  Prometheus exporter for Redis metrics. Supports Redis 2.x, 3.x, 4.x, and 5.x.
> 
> 
> Attached a tested and working packaging (based on the one from the
> prometheus-node-exporter, where Tina agreed to the relicensing to
> match upstream), where only the Uploaders, and ITP bug need to be
> filled, and the packaging imported into git.

Attached an update for the latest upstream which removed the need for
the embedded vendoring. And with few minor packaging improvements.

Thanks,
Guillem


prometheus-redis-exporter_1.5.2-1.debian.tar.xz
Description: application/xz

Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: prometheus-redis-exporter
  Version : 1.4.0
  Upstream Author : Oliver
* URL : https://github.com/oliver006/redis_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for Redis metrics

 Prometheus exporter for Redis metrics. Supports Redis 2.x, 3.x, 4.x, and 5.x.


Attached a tested and working packaging (based on the one from the
prometheus-node-exporter, where Tina agreed to the relicensing to
match upstream), where only the Uploaders, and ITP bug need to be
filled, and the packaging imported into git.

Thanks,
Guillem


prometheus-redis-exporter_1.4.0-1.debian.tar.xz
Description: application/xz

Bug#953663: RFP: golang-github-valyala-quicktemplate -- fast, powerful, yet easy to use template engine for Go (lborary)

[Guillem Jover]

Hi!

On Wed, 2020-03-11 at 22:23:18 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Tags: patch
> 
> * Package name: golang-github-valyala-quicktemplate
>   Version : 1.4.1
>   Upstream Author : Aliaksandr Valialkin
> * URL : https://github.com/valyala/quicktemplate
> * License : Expat
>   Programming Lang: Go
>   Description : fast, powerful, yet easy to use template engine for Go 
> (lborary)


> This is a required dependency for victoria-metrics.
> 
> Attached a tested and working packaging, where only the Uploaders, and
> ITP bug need to be filled, and the packaging imported into git.

I just noticed this was shipping a «basicserver» program. Attached an
updated packaging correcting that.

Thanks,
Guillem


golang-github-valyala-quicktemplate_1.4.1-1.debian.tar.xz
Description: application/xz

Bug#953658: RFP: golang-github-allegro-bigcache -- efficient cache for gigabytes of data written in Go (library)

[Guillem Jover]

Hi!

On Wed, 2020-03-11 at 22:20:03 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Tags: patch
> 
> * Package name: golang-github-allegro-bigcache
>   Version : 2.1.7
>   Upstream Author : Allegro Tech
> * URL : https://github.com/allegro/bigcache
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : efficient cache for gigabytes of data written in Go 
> (library)


> This is a required dependency for victoria-metrics.
> 
> Attached a tested and working packaging, where only the Uploaders, and
> ITP bug need to be filled, and the packaging imported into git.

Just noticed this was shipping a «server» binary. Attached an updated
packaing correcting that. :)

Thanks,
Guillem


golang-github-allegro-bigcache_2.1.7-1.debian.tar.xz
Description: application/xz

Bug#953665: RFP: golang-github-victoriametrics-metrics -- lightweight alternative to prometheus/client_golang (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-victoriametrics-metrics
  Version : 1.10.1
  Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/metrics
* License : Expat
  Programming Lang: Go
  Description : lightweight alternative to prometheus/client_golang 
(library)

 This is a lightweight package for exporting metrics in Prometheus format.
 .
 Features:
  * Lightweight. Has minimal number of third-party dependencies and all these
deps are small.
  * Easy to use.
  * Fast.
  * Allows exporting distinct metric sets via distinct endpoints.
  * Supports easy-to-use histograms, which just work without any tuning.
 .
 Limitations:
  * It doesn't implement advanced functionality from
github.com/prometheus/client_golang.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-victoriametrics-metrics_1.10.1-1.debian.tar.xz
Description: application/xz

Bug#953666: RFP: victoria-metrics -- fast, cost-effective and scalable time series database

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: victoria-metrics
  Version : 1.34.2
  Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/VictoriaMetrics
* License : Apache-2.0
  Programming Lang: Go
  Description : fast, cost-effective and scalable time series database

 VictoriaMetrics is a fast, cost-effective and scalable time-series database.
 It can be used as long-term remote storage for Prometheus.
 .
 Prominent features:
  * Supports Prometheus querying API, so it can be used as Prometheus
drop-in replacement in Grafana. VictoriaMetrics implements MetricsQL
query language, which is inspired by PromQL.
  * Supports global query view. Multiple Prometheus instances may write
data into VictoriaMetrics. Later this data may be used in a single query.
  * High performance and good scalability for both inserts and selects.
Outperforms InfluxDB and TimescaleDB by up to 20x.
  * Uses 10x less RAM than InfluxDB when working with millions of unique time
series (aka high cardinality).
  * Optimized for time series with high churn rate. Think about
prometheus-operator metrics from frequent deployments in Kubernetes.
  * High data compression, so up to 70x more data points may be crammed into
limited storage comparing to TimescaleDB.
  * Optimized for storage with high-latency IO and low IOPS (HDD and network
storage in AWS, Google Cloud, Microsoft Azure, etc).
  * A single-node VictoriaMetrics may substitute moderately sized clusters
built with competing solutions such as Thanos, M3DB, Cortex, InfluxDB or
TimescaleDB.
  * Easy operation:
- VictoriaMetrics consists of a single small executable without external
  dependencies.
- All the configuration is done via explicit command-line flags with
  reasonable defaults.
- All the data is stored in a single directory pointed by
  -storageDataPath flag.
- Easy and fast backups from instant snapshots to S3 or GCS with
  vmbackup / vmrestore.
  * Storage is protectedfrom corruption on unclean shutdown (i.e. OOM,
hardware reset or kill -9) thanks to the storage architecture.
  * Supports metrics' scraping, ingestion and backfilling (#backfilling)
via the following protocols:
- Metrics from Prometheus exporters such as node_exporter.
- Prometheus remote write API
- InfluxDB line protocol
- Graphite plaintext protocol with tags if -graphiteListenAddr is set.
- OpenTSDB put message if -opentsdbListenAddr is set.
- HTTP OpenTSDB /api/put requests if -opentsdbHTTPListenAddr is set.
- /api/v1/import.
  * Ideally works with big amounts of time series data from Kubernetes, IoT
sensors, connected cars, industrial telemetry, financial data and
various Enterprise workloads.
  * Has open source cluster version.


Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


victoria-metrics_1.34.2-1.debian.tar.xz
Description: application/xz

Bug#953664: RFP: golang-github-victoriametrics-fastcache -- fast thread-safe in-memory cache for big number of entries in Go (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-victoriametrics-fastcache
  Version : 1.5.6
  Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/fastcache
* License : Expat
  Programming Lang: Go
  Description : fast thread-safe in-memory cache for big number of entries 
in Go (library)

 Features:
  * Fast. Performance scales on multi-core CPUs.
  * Thread-safe. Concurrent goroutines may read and write into a single cache
instance.
  * The fastcache is designed for storing big number of entries without GC
overhead.
  * Fastcache automatically evicts old entries when reaching the maximum
cache size set on its creation.
  * Simple API.
  * Simple source code.
  * Cache may be saved to file and loaded from file.
  * Works on Google AppEngine.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-victoriametrics-fastcache_1.5.6-1.debian.tar.xz
Description: application/xz

Bug#953660: RFP: golang-github-valyala-fastjson -- fast JSON parser and validator for Go (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-valyala-fastjson
  Version : 1.5.0
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/fastjson
* License : Expat
  Programming Lang: Go
  Description : fast JSON parser and validator for Go (library)

 No custom structs, no code generation, no reflection.
 .
 Features:
  * Fast. As usual, up to 15x faster than the standard encoding/json.
  * Parses arbitrary JSON without schema, reflection, struct magic and code
generation contrary to easyjson.
  * Provides a simple API.
  * Outperforms jsonparser and gjson when accessing multiple unrelated fields,
since fastjson parses the input JSON only once.
  * Validates the parsed JSON unlike jsonparser and gjson.
  * May quickly extract a part of the original JSON with
Value.Get(...).MarshalTo and modify it with Del and Set functions.
  * May parse array containing values with distinct types (aka non-homogenous
types). For instance, fastjson easily parses the following JSON array
[123, "foo", [456], {"k": "v"}, null].
  * fastjson preserves the original order of object items when calling
Object.Visit.
 .
 Known limitations:
  * Requies extra care to work with - references to certain objects
recursively returned by Parser must be released before the next call to
Parse.  Otherwise the program may work improperly. The same applies to
objects returned by Arena.
  * Cannot parse JSON from io.Reader.
 .
 Security:
  * fastjson shouldn't crash or panic when parsing input strings specially
crafted by an attacker. It must return error on invalid input JSON.
  * fastjson requires up to sizeof(Value) * len(inputJSON) bytes of memory
for parsing inputJSON string. Limit the maximum size of the inputJSON
before parsing it in order to limit the maximum memory usage.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-valyala-fastjson_1.5.0-1.debian.tar.xz
Description: application/xz

Bug#953662: RFP: golang-github-valyala-histogram -- fast histograms for Go (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-valyala-histogram
  Version : 1.0.1
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/histogram
* License : Expat
  Programming Lang: Go
  Description : Fast histograms for Go

 Fast histograms for Go.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-valyala-histogram_1.0.1-1.debian.tar.xz
Description: application/xz

Bug#953663: RFP: golang-github-valyala-quicktemplate -- fast, powerful, yet easy to use template engine for Go (lborary)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-valyala-quicktemplate
  Version : 1.4.1
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/quicktemplate
* License : Expat
  Programming Lang: Go
  Description : fast, powerful, yet easy to use template engine for Go 
(lborary)

 Optimized for speed, zero memory allocations in hot paths. Up to 20x faster
 than html/template.
 .
 Inspired by the Mako templates philosophy.
 .
 Features:
  * Extremely fast. Templates are converted into Go code and then compiled.
  * Quicktemplate syntax is very close to Go - there is no need to learn yet
another template language before starting to use quicktemplate.
  * Almost all bugs are caught during template compilation, so production
suffers less from template-related bugs.
  * Easy to use.
  * Powerful. Arbitrary Go code may be embedded into and mixed with templates.
Be careful with this power - do not query the database and/or external
resources from templates unless you miss the PHP way in Go :) This power
is mostly for arbitrary data transformations.
  * Easy to use template inheritance powered by Go interfaces.
  * Templates are compiled into a single binary, so there is no need to copy
template files to the server.
  .
  Drawbacks:
  * Templates cannot be updated on the fly on the server, since they are
compiled into a single binary. Take a look at fasttemplate
(https://github.com/valyala/fasttemplate) if you need a fast
template engine for simple dynamically updated templates.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-valyala-quicktemplate_1.4.1-1.debian.tar.xz
Description: application/xz

Bug#953661: RFP: golang-github-valyala-gozstd -- go wrapper for zstd (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-valyala-gozstd
  Version : 1.6.4
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/gozstd
* License : Expat
  Programming Lang: Go
  Description : go wrapper for zstd (library)

 This package provides Go bindings for the libzstd C library.
 .
 Features:
 * Simple API.
 * Optimized for speed. The API may be easily used in zero allocations mode.
 * Compress* and Decompress* functions are optimized for high concurrency.
 * Proper Writer.Flush for network apps.
 * Supports the following features from upstream zstd:
   - Block / stream compression / decompression with all the supported
 compression levels and with dictionary support.
   - Dictionary building from a sample set. The created dictionary may be
 saved to persistent storage / transfered over the network.
   - Dictionary loading for compression / decompression.
 .
 There is also StreamCompress and Writer for stream compression and
 StreamDecompress and Reader for stream decompression.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-valyala-gozstd_1.6.4-1.debian.tar.xz
Description: application/xz

Bug#953659: RFP: golang-github-valyala-fastrand -- fast and scalable pseudorandom generator for Go (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-valyala-fastrand
  Version : 1.0.0
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/fastrand
* License : Expat
  Programming Lang: Go
  Description : fast and scalable pseudorandom generator for Go (library)

 Fast pseudorandom number generator.
 .
 Features:
  * Optimized for speed.
  * Performance scales on multiple CPUs.
 .
 It work by using sync.Pool for maintaining "per-CPU" pseudorandom
 number generators.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-valyala-fastrand_1.0.0-1.debian.tar.xz
Description: application/xz

Bug#953658: RFP: golang-github-allegro-bigcache -- efficient cache for gigabytes of data written in Go (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-allegro-bigcache
  Version : 2.1.7
  Upstream Author : Allegro Tech
* URL : https://github.com/allegro/bigcache
* License : Apache-2.0
  Programming Lang: Go
  Description : efficient cache for gigabytes of data written in Go 
(library)

 Fast, concurrent, evicting in-memory cache written to keep big number of
 entries without impact on performance. BigCache keeps entries on heap
 but omits GC for them. To achieve that, operations on byte slices take
 place, therefore entries (de)serialization in front of the cache will
 be needed in most use cases.


This is a required dependency for victoria-metrics.

Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.

Thanks,
Guillem


golang-github-allegro-bigcache_2.1.7-1.debian.tar.xz
Description: application/xz

Bug#899425: O: gkremldk -- mldonkey plugin for gkrellm2

[Guillem Jover]

Control: retitle -1 RM: gkremldk -- RoQA; dead upstream, unmaintained, bogus 
source format
Control: reassign -1 ftp.debian.org

Hi!

I was about to NMU this package to fix its source format not matching
its version format, then I noticed that upstream has just disappeared.

   → 404

So I think it would be best to instead remove it.

Thanks,
Guillem

Bug#644757: Removing ocaml-book?

[Guillem Jover]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: ocaml-book -- RoQA: unmaintained, partial, non-free, 
bogus source format

On Sat, 2014-01-25 at 23:38:19 +0200, Adrian Bunk wrote:
> since ocaml-book is:
> - orphaned since 2011 and
> - in non-free and
> - a small subset of what a user gets when goes to [1]
> I wonder whether it actually makes sense to keep ocaml-book in non-free, 
> or whether it could be removed.

> [1] http://caml.inria.fr/resources/doc/index.en.html

Yes. In addition I was about to NMU it to fix its bogus source format
relative to its source version, and noticed it's in non-free and has
been unmaintained now for a very long time.

Thanks,
Guillem

Bug#952776: RFP: libprometheus-tiny-perl -- tiny module to export monitoring metrics for Prometheus

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libprometheus-tiny-perl
  Version : 0.004
  Upstream Author : Rob N ★ 
* URL : https://metacpan.org/release/Prometheus-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : tiny module to export monitoring metrics for Prometheus

 Prometheus::Tiny is a minimal metrics client for the Prometheus time-series
 database, that can be used to instrument a service so that it can export
 monitoring metrics so that Prometheus compatible servers can collect them.
 .
 It does the following things differently to Net::Prometheus:
  * No setup. No need to pre-declare metrics to get something useful.
  * Labels are passed in a hash. Positional parameters get awkward.
  * No inbuilt collectors, PSGI apps, etc. Just the metrics.
  * No different metric types. You get what you ask for.


This package makes it easier to write Prometheus clients, that need to
get metrics from external sources, otherwise you need to create your
own derived types.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Uploader added assuming
the Perl team wants to take it. :)

Thanks,
Guillem


libprometheus-tiny-perl_0.004-1.debian.tar.xz
Description: application/xz

Bug#950903: ITP: liburing -- Linux kernel io_uring access library

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: liburing
  Version : 0.4
  Upstream Author : Jens Axboe 
* URL : https://git.kernel.dk/cgit/liburing/
* License : LGPL and MIT/X
  Programming Lang: C
  Description : Linux kernel io_uring access library

 liburing provides helpers to setup and teardown io_uring instances,
 and also a simplified interface for applications that don't need (or
 want) to deal with the full kernel side implementation.


The liburing library is supposed so supercede the libaio library which
I maintain too, so it makes sense to handle both. :)

Thanks,
Guillem

Bug#919190: keepassxc-browser status?

[Guillem Jover]

Hi!

On Thu, 2019-11-14 at 19:23:08 +0800, Bruno Kleinert wrote:
> Am Donnerstag, den 14.11.2019, 12:03 +0100 schrieb Guillem Jover:
> > I noticed that the keepassxc-browser packages that were sitting in
> > NEW(<https://ftp-master.debian.org/new.html>;), disappeared from
> > there andare not in the archive either. Does this mean they got
> > REJECTED?

> yes it got rejected. I discussed the reason for rejection with upstream
> and a resolution is in the works. I will re-upload to NEW as soon as
> the solution is released.

Thanks for the update! Much appreciated.

Regards,
Guillem

Bug#919190: keepassxc-browser status?

[Guillem Jover]

Hi!

I noticed that the keepassxc-browser packages that were sitting in NEW
(), disappeared from there and
are not in the archive either. Does this mean they got REJECTED?

Thanks,
Guillem

Bug#944629: RFP: libcatalyst-plugin-session-store-redis-perl -- Redis Session store for Catalyst

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libcatalyst-plugin-session-store-redis-perl
  Version : 0.09
  Upstream Author : Thomas Klausner 
* URL : 
https://metacpan.org/release/Catalyst-Plugin-Session-Store-Redis
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Redis Session store for Catalyst

 Catalyst::Plugin::Session::Store::Redis is a session storage plugin
 for Catalyst that uses the Redis (https://redis.io/) key-value database.


This package is useful when wanting to interact via Perl using the
Catalyst framework with a Redis instance.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and
Vcs fields added if appropriate.

Thanks,
Guillem


libcatalyst-plugin-session-store-redis-perl_0.09-1.debian.tar.xz
Description: application/xz

Bug#924659: ITP: fossology -- FOSSology is an open source license compliance software system and toolkit.

[Guillem Jover]

Hi!

On Fri, 2019-03-15 at 20:27:57 +0530, Gaurav Mishra wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gaurav Mishra 

>   Package name : fossology
>   Version : 3.4.0
>   Upstream Author : Michael Jaeger 
>   URL : https://www.fossology.org/
>   License : GPL-2.0-only, LGPL-2.1-only
>   Programming Lang: C, C++, PHP
>   Description : FOSSology is an open source license compliance software
> system and toolkit.
> 
>  FOSSology is an open source license compliance software system and
> toolkit. As a toolkit you can run license, copyright and export control
> scans from the command line. As a system, a database and web ui are
> provided to give you a compliance workflow. License, copyright and export
> scanners are tools used in the workflow.
> 
>  - Why is this package useful/relevant?
>- FOSSology is a famous tool used for open source license compliance.
>  We have a large database of users which can be benifited by
>  publishing this as a Debian package.
>  - Do you use it?
>- You can check https://www.fossology.org/ to get a list of compaines
>  and organizations using FOSSology.
>  - How do you plan to maintain it?
>- FOSSology is currently maintained at
>  https://github.com/fossology/fossology. I have created a mirror for
>  the same at https://salsa.debian.org/fossology-team/fossology.
>  - Are you looking for co-maintainers or a sponsor?
>- We are looking for a sponsor to help us publish FOSSology as a
>  Debian package.

JFYI:

  ,---
  $ deb-why-removed fossology
  Date: Sun, 10 Jun 2012 09:58:31 +
  Ftpmaster: Luca Falavigna
  Suite: unstable
  Sources:
   fossology_1.2.0-3.1
  Binaries:
   fossology_1.2.0-3.1 [all]
   fossology-agents_1.2.0-3.1 [amd64, armel, armhf, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
   fossology-agents-single_1.2.0-3.1 [amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
   fossology-common_1.2.0-3.1 [amd64, armel, armhf, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
   fossology-db_1.2.0-3.1 [all]
   fossology-dev_1.2.0-3.1 [amd64, armel, armhf, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
   fossology-scheduler_1.2.0-3.1 [amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
   fossology-scheduler-single_1.2.0-3.1 [amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
   fossology-web_1.2.0-3.1 [all]
   fossology-web-single_1.2.0-3.1 [all]
  Reason: RoQA; unmaintained, RC buggy
  Bug: 656591
  Also-Bugs: 591107 592025 595593 627771 639468 658953 674381
  `---

Thanks,
Guillem

Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc

[Guillem Jover]

Hi!

On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Dmitry Bogatov 
> 
> * Package name : build-alternative
>   Version  : 0.0.1
>   Upstream Author  : Dmitry Bogatov 
> * Url  : https://salsa.debian.org/kaction/build-alternative
> * Licenses : GPL-3+
>   Programming Lang : shell
>   Section  : devel
> 
>  This package provide makefile snippet, that abstract away
>  several issues, related to building package with diet libc.
>  .
>   * diet libc is not supported on every Debian architecture
>   * code to check for build profiles is repetive
>  .
>  Regular users do not need to install this package, it is only
>  useful to Debian Contributors.

Hmm this package name looks extremely generic for what it is described
to be used for. Could you name it something else that includes either
dietlibc in its name or at least libc or similar?

Thanks,
Guillem

Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

[Guillem Jover]

Hi!

On Fri, 2019-02-15 at 17:24:24 +0100, Andrej Shadura wrote:
> Speaking of which, maybe it would also make sense to merge my changes
> in?
> 
> https://bitbucket.org/andrew_shadura/start-stop-daemon-isolate/commits/8646be59e3fde0b22f84a842ef5729a5de08fd3b

This being ,
which I had the recollection was pending on your side? Maybe there was
a communication breakdown somewhere there. :)

Thanks,
Guillem

Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

[Guillem Jover]

Hi!

On Fri, 2019-02-15 at 10:46:43 -0500, Daniel Kahn Gillmor wrote:
> Control: clone 922353 -2
> Control: reassign -2 dpkg
> Control: retitle -2 start-stop-daemon should support socket-activation via 
> the sd_listen_fds(3) convention
> Control: severity -2 wishlist

Thanks.

> On Fri 2019-02-15 04:34:47 +0100, Guillem Jover wrote:
> > Another option would be to implement this in start-stop-daemon, like
> > the similar support for the systemd readiness protocol was recently
> > implemented there too.
> 
> Thanks for the suggestion!  How widely-distributed is start-stop-daemon
> outside of debian?  I see it's been ported to OpenBSD; are they
> syncing from upstream?

<https://wiki.debian.org/Teams/Dpkg/Downstream>. For the BSDs to use
this more seriously the code would probably need to be split into its
own project, so that it does not pollute their licensing. Its current
"license" might also need to be clarified (PD), and "relicensed" into
MIT or similar.

This is something I've actually pondered doing anyway, so this might
be a good excuse, I guess.

> The code i have is just python3 right now (simple argument parsing made
> development much quicker), but it's not too terrible to do it in C.

Yes, and it should be pretty generic and portable.

> I'm opening this as a wishlist issue for dpkg just so we don't lose
> track of it, since it might take me some cycles to get the C
> implementation in shape.  If anyone else wants to beat me to it, i
> certainly wouldn't complain :)

I'll probably look into it once I've gone over some of the immediate
stuff I have on my plate, if there's been no patch submitted by then.
:)

Thanks,
Guillem

Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

[Guillem Jover]

Hi!

On Thu, 2019-02-14 at 17:36:31 -0500, Daniel Kahn Gillmor wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Kahn Gillmor 
> 
> * Package name: socket-activate
>   Version : 0.1
>   Upstream Author : Daniel Kahn Gillmor
> * URL : https://gitlab.com/dkg/socket-activate
> * License : GPL
>   Programming Lang: Python
>   Description : Run a socket-activated daemon with minimal dependencies

> socket-activate makes it possible to use socket-activated services on
> Unix-based systems that don't have systemd installed at all.
> 
> It implements the environment variable and file descriptor convention
> described in sd_listen_fds(3) without using any external code or
> dependencies from systemd.  The only thing it depends on is python3
> itself.
> 
> See https://bugs.debian.org/922082 for more discussion of the
> motivation for this project.  Future versions might be in C, so that
> even python isn't required, but the initial python implementation is
> intended to validate the interface.

Another option would be to implement this in start-stop-daemon, like
the similar support for the systemd readiness protocol was recently
implemented there too.

Thanks,
Guillem

Bug#921980: O: posixtestsuite -- POSIX conformance test suite report log

[Guillem Jover]

Package: wnpp
Severity: normal

I intend to orphan the posixtestsuite package.

The package description is:
 The POSIX Test Suite is a free (as in speech) test suite with the goal
 of  performing conformance, functional, and stress testing of the IEEE
 1003.1-2001 System Interfaces specification in a manner that is agnostic
 to any given implementation.
 .
 This package only provides the test suite results in a log file. If you
 want to run the testsuite, use the source package of the same name (e.g.
 apt-get source posixtestsuite).


Upstream is dead, as it was merged into the Linux Test Project some
time ago:

  


anyone wanting to take over, might prefer to spend the effort instead
ressurrecting the ltp package. See #672776.

Thanks,
Guillem

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

Hi!

On Sat, 2018-10-06 at 15:16:07 +0800, Yangfl wrote:
> Yangfl  于2018年9月22日周六 上午9:22写道：
> > Guillem Jover  于2018年9月22日周六 上午8:30写道：
> > > The attached is what I'd include.
> >
> > $ ./a.out --test
> > md5 self-test completed successfully.
> > $ ldd ./a.out
> > linux-vdso.so.1 (0x7ffc941d6000)
> > libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x7f0388a58000)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f03888c4000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0388707000)
> > /lib64/ld-linux-x86-64.so.2 (0x7f0388c8b000)
> >
> > Looks great. Thanks!

> Any plan to release a new libmd version?

Yes, had this in mind, and was planning on a release during this week,
just got entangled with other stuff. I'll probably release today or
tomorrow.

Thanks,
Guillem

Bug#910252: ITP: libnbcompat -- NetBSD compatibility library

[Guillem Jover]

Hi!

On Thu, 2018-10-04 at 08:28:57 -0500, John Goerzen wrote:
> On Thu, Oct 04 2018, Guillem Jover wrote:
> > Hmm, what does this library provide that is required by mtree-netbsd not
> > available in glibc, libbsd and libmd? Perhaps even freebsd-glue?
> >
> > I've skimmed over the functionality and it seems most of it is already
> > covered by those. If there's still stuff needed I'm always happy to add
> > it to libbsd or libmd as required!

> You are correct that the functionality is generally available.  The
> problem is that the interfaces are different.  nbconfig.h, for instance,
> defines a number of HAVE_* macros that are used while building mtree.
> nbconfig.h includes a number of system header files (stdio.h, etc.) that
> cause *numerous* build errors if missing.  There are also functions for
> things like hashing files that take different numbers of parameters,
> etc.

I see the packages have already gone through NEW, so I've taken a
look. And I've almost got mtree-netbsd building using just libmd and
libbsd. I'll be releasing new upstream versions fixing or adding the
missing stuff:

  - libmd had bogus compat macros for SHA512, and missing ones for
SHA384.
  - libbsd is missing the pwcache modules from the BSDs, which I'll
be adding.
  - libbsd is missing a  that implicitly includes
, I'll be adding that.

Then I've got some minimal patches for mtree-netbsd, which fix or improve
things there, that I'll be sending your way once I've finished with the
above. At which point I think it would be nice to drop libnbcompat
completely?

The point of creating libmd and libbsd and switching projects to use
those, was to have such BSD compatibility library in a single place
which can be fixed centrallly, and to reduce embedded code copies. So
adding yet similar library would make the situation confusing and
might distract from such unifiying efforts. :)

> I also considered, for a bit, whether to even make libnbcompat be a
> separate package.  I concluded yes, because:
> 
> 1) It has its own standalone configure,
> 
> 2) It must be configured and built before mtree can be configured,
> 
> 3) Even on NetBSD, mtree requires libnbcompat to build (the #include
>  is not wrapped inside any conditional macro)
> 
> Because of #1 and #2, just including it in mtree itself would cause the
> build system to somewhat violate the usual principles of how to build.

I really think libnbcompat should be completely unnecessary. :) And if
there'd be new features required my mtree-netbsd in the future I'm
always happy to consider new additions to these libraries if they make
sense!

Thanks,
Guillem

Bug#910252: ITP: libnbcompat -- NetBSD compatibility library

[Guillem Jover]

Hi!

On Wed, 2018-10-03 at 20:57:30 -0500, John Goerzen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: John Goerzen 

> * Package name: libnbcompat
>   Version : 20180822
>   Upstream Author : Joerg Sonnenberger  and the NetBSD 
> PRoject
> * URL : 
> http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/pkgtools/libnbcompat/README.html
> * License : BSD
>   Programming Lang: C
>   Description : NetBSD compatibility library
> 
> libnbcompat is designed to let non-NetBSD operating systems execute code
> that is part of the NetBSD pkgsrc repository.  It is, in particular,
> required for building the NetBSD mtree, which has some distinct advantages
> over the FreeBSD mtree already in the Debian repos and is being adopted
> by FreeBSD.

Hmm, what does this library provide that is required by mtree-netbsd not
available in glibc, libbsd and libmd? Perhaps even freebsd-glue?

I've skimmed over the functionality and it seems most of it is already
covered by those. If there's still stuff needed I'm always happy to add
it to libbsd or libmd as required!

Thanks,
Guillem

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

On Fri, 2018-09-21 at 19:35:53 +0200, Guillem Jover wrote:
> On Sat, 2018-09-22 at 00:13:47 +0800, Yangfl wrote:
> > Guillem Jover  于2018年9月21日周五 上午7:42写道：
> > > Something like the attached patch would do I guess? I'm not sure if
> > > I'd want to expose those unconditionally, as that might pollute the
> > > namespace.
> > 
> > Please find the attached md5main-md.c, taken from libmd5-rfc but
> > modified to be compiled with -lmd. Notice the segfault here. Clearly
> > MD5End supplies the hash in ASCII hex string, but md5_finish in raw
> > char array. That's not the same.
> 
> Ah indeed sorry, I used initially MD5Final() which is the correct one
> here, but switched to MD5End() because it was failing the libmd test
> suite.
> 
> Patch updated, I'll fix the test suite later today.

The attached is what I'd include.

Thanks,
Guillem
diff --git i/include/md5.h w/include/md5.h
index dee2bf4..2f8b167 100644
--- i/include/md5.h
+++ w/include/md5.h
@@ -47,4 +47,17 @@ char	*MD5Data(const uint8_t *, size_t, char *);
 }
 #endif
 
+/*
+ * Interface compatibility with Aladdin Enterprises independent
+ * implemntation from RFC 1321.
+ */
+
+typedef uint8_t md5_byte_t;
+typedef uint32_t md5_word_t;
+typedef MD5_CTX md5_state_t;
+
+#define md5_init(pms) MD5Init(pms)
+#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
+#define md5_finish(pms, digest) MD5Final(digest, pms)
+
 #endif /* _MD5_H_ */
diff --git i/test/md5.c w/test/md5.c
index 5dac6e1..f18f398 100644
--- i/test/md5.c
+++ w/test/md5.c
@@ -30,12 +30,55 @@
 #include 
 #include 
 
+static int
+hexchar2bin(int c)
+{
+	if (c >= '0' && c <= '9')
+		return c - '0';
+	else if (c >= 'a' && c <= 'f')
+		return c - 'a' + 10;
+	else if (c >= 'A' && c <= 'F')
+		return c - 'A' + 10;
+	assert(!"invalid hexadecimal input");
+}
+
+static void
+hex2bin(uint8_t *bin, const char *str, size_t bin_len)
+{
+	int i;
+
+	for (i = 0; i < bin_len; i++)
+		bin[i] = hexchar2bin(str[i * 2]) << 4 |
+		 hexchar2bin(str[i * 2 + 1]);
+}
+
 void
-test_md5(const char *digest, const char *string)
+test_md5(const char *digest_str, const char *string)
 {
-	char result[MD5_DIGEST_STRING_LENGTH];
+	uint8_t digest[MD5_DIGEST_LENGTH];
+	uint8_t result[MD5_DIGEST_LENGTH];
+	char result_str[MD5_DIGEST_STRING_LENGTH];
+	MD5_CTX ctx;
+	md5_state_t pms;
+
+	hex2bin(digest, digest_str, MD5_DIGEST_LENGTH);
+
+	assert(strcmp(digest_str, MD5Data(string, strlen(string), result_str)) == 0);
+
+	MD5Init();
+	MD5Update(, string, strlen(string));
+	MD5End(, result_str);
+	assert(strcmp(digest_str, result_str) == 0);
+
+	MD5Init();
+	MD5Update(, string, strlen(string));
+	MD5Final(result, );
+	assert(memcmp(digest, result, MD5_DIGEST_LENGTH) == 0);
 
-	assert(strcmp(digest, MD5Data(string, strlen(string), result)) == 0);
+	md5_init();
+	md5_append(, string, strlen(string));
+	md5_finish(, result);
+	assert(memcmp(digest, result, MD5_DIGEST_LENGTH) == 0);
 }
 
 int

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

On Sat, 2018-09-22 at 00:13:47 +0800, Yangfl wrote:
> Guillem Jover  于2018年9月21日周五 上午7:42写道：
> > Something like the attached patch would do I guess? I'm not sure if
> > I'd want to expose those unconditionally, as that might pollute the
> > namespace.
> 
> Please find the attached md5main-md.c, taken from libmd5-rfc but
> modified to be compiled with -lmd. Notice the segfault here. Clearly
> MD5End supplies the hash in ASCII hex string, but md5_finish in raw
> char array. That's not the same.

Ah indeed sorry, I used initially MD5Final() which is the correct one
here, but switched to MD5End() because it was failing the libmd test
suite.

Patch updated, I'll fix the test suite later today.

Thanks,
Guillem
diff --git i/include/md5.h w/include/md5.h
index dee2bf4..2f8b167 100644
--- i/include/md5.h
+++ w/include/md5.h
@@ -47,4 +47,17 @@ char	*MD5Data(const uint8_t *, size_t, char *);
 }
 #endif
 
+/*
+ * Interface compatibility with Aladdin Enterprises independent
+ * implemntation from RFC 1321.
+ */
+
+typedef uint8_t md5_byte_t;
+typedef uint32_t md5_word_t;
+typedef MD5_CTX md5_state_t;
+
+#define md5_init(pms) MD5Init(pms)
+#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
+#define md5_finish(pms, digest) MD5Final(digest, pms)
+
 #endif /* _MD5_H_ */

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

On Fri, 2018-09-21 at 01:13:31 +0200, Guillem Jover wrote:
> Hi!
> 
> On Wed, 2018-09-19 at 00:31:26 +0800, Yangfl wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Yangfl 
> > 
> > * Package name: libmd5-rfc
> >   Version : 0.0+20020413
> >   Upstream Author : Aladdin Enterprises
> > * URL : https://sourceforge.net/projects/libmd5-rfc/
> > * License : zlib
> >   Programming Lang: C
> >   Description : RFC1321-based (RSA-free) MD5 library
> >  This is a very small C library implementing RFC1321, the MD5 message digest
> >  function. Unlike the existing W3C libmd5, it was written from the
> >  specifications (not the sample code) in RFC1321, and therefore is not 
> > required
> >  to acknowledge RSA in any way.
> 
> There's already libmd in the archive which contains an RSA-free MD5
> implementation. I see the interface is not exactly the same, but I
> think a handful of macros would easily take care of that, and I'd be
> happy to include those in libmd's md5.h.
> 
> Also the current package provides /usr/include/md5.h which will
> conflict with libmd-dev.

Something like the attached patch would do I guess? I'm not sure if
I'd want to expose those unconditionally, as that might pollute the
namespace.

Thanks,
Guillem
diff --git i/include/md5.h w/include/md5.h
index dee2bf4..72912b5 100644
--- i/include/md5.h
+++ w/include/md5.h
@@ -47,4 +47,17 @@ char	*MD5Data(const uint8_t *, size_t, char *);
 }
 #endif
 
+/*
+ * Interface compatibility with Aladdin Enterprises independent
+ * implemntation from RFC 1321.
+ */
+
+typedef uint8_t md5_byte_t;
+typedef uint32_t md5_word_t;
+typedef MD5_CTX md5_state_t;
+
+#define md5_init(pms) MD5Init(pms)
+#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
+#define md5_finish(pms, digest) MD5End(pms, digest)
+
 #endif /* _MD5_H_ */
diff --git i/test/md5.c w/test/md5.c
index 5dac6e1..2bf6cb4 100644
--- i/test/md5.c
+++ w/test/md5.c
@@ -34,8 +34,20 @@ void
 test_md5(const char *digest, const char *string)
 {
 	char result[MD5_DIGEST_STRING_LENGTH];
+	MD5_CTX ctx;
+	md5_state_t pms;
 
 	assert(strcmp(digest, MD5Data(string, strlen(string), result)) == 0);
+
+	MD5Init();
+	MD5Update(, string, strlen(string));
+	MD5End(, result);
+	assert(strcmp(digest, result) == 0);
+
+	md5_init();
+	md5_append(, string, strlen(string));
+	md5_finish(, result);
+	assert(strcmp(digest, result) == 0);
 }
 
 int

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

Hi!

On Wed, 2018-09-19 at 00:31:26 +0800, Yangfl wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Yangfl 
> 
> * Package name: libmd5-rfc
>   Version : 0.0+20020413
>   Upstream Author : Aladdin Enterprises
> * URL : https://sourceforge.net/projects/libmd5-rfc/
> * License : zlib
>   Programming Lang: C
>   Description : RFC1321-based (RSA-free) MD5 library
>  This is a very small C library implementing RFC1321, the MD5 message digest
>  function. Unlike the existing W3C libmd5, it was written from the
>  specifications (not the sample code) in RFC1321, and therefore is not 
> required
>  to acknowledge RSA in any way.

There's already libmd in the archive which contains an RSA-free MD5
implementation. I see the interface is not exactly the same, but I
think a handful of macros would easily take care of that, and I'd be
happy to include those in libmd's md5.h.

Also the current package provides /usr/include/md5.h which will
conflict with libmd-dev.

Thanks,
Guillem

Bug#840742: RFP: golang-github-kardianos-service -- Run go programs as a service on major platforms

[Guillem Jover]

Hi!

On Fri, 2016-10-14 at 13:45:40 +0200, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Tags: patch
> Control: block 793749 by -1
> 
> * Package name: golang-github-kardianos-service
>   Version : 0.0~git20160824.0.7a88211-1
>   Upstream Author : Daniel Theophanes
> * URL : https://github.com/kardianos/service
> * License : zlib
>   Programming Lang: Go
>   Description : Run go programs as a service on major platforms
> 
>  service will install / un-install, start / stop, and run a program as a
>  service (daemon). Currently supports Linux/(systemd | Upstart | SysV),
>  OSX/Launchd and Windows XP+.
>  .
>  Windows controls services by setting up callbacks that are non-trivial. This
>  is very different than other systems. This package provides the same API
>  despite the substantial differences. It also can be used to detect how a
>  program is called, from an interactive terminal or from a service manager.

> Attached a working and tested packaging, where only the ITP bug number
> needs to be filled in the debian/changelog, Maintainer changed, and Vcs
> fields added.

Attached updated packaging to current standards.

Thanks,
Guillem


golang-github-kardianos-service_0.0~git20160824.0.7a88211-0.1.debian.tar.xz
Description: application/xz

Bug#909144: RFP: golang-github-tidwall-gjson -- JSON Parser for Go

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-tidwall-gjson
  Version : 1.1.3-1
  Upstream Author : Josh Baker
* URL : https://github.com/tidwall/gjson
* License : Expat
  Programming Lang: Go
  Description : JSON Parser for Go

 Go package that provides a fast and simple way to get values from a json
 document. It has features such as one line retrieval , dot notation paths,
 iteration, and parsing json lines.


This package is a dependency of the latest telegraf upstream release.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Maintainer changed.

Thanks,
Guillem


golang-github-tidwall-gjson_1.1.3-0.1.debian.tar.xz
Description: application/xz

Bug#909143: RFP: golang-github-tidwall-match -- simple string pattern matcher for Go

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-tidwall-match
  Version : 0.0~git20171002.1731857-1
  Upstream Author : Josh Baker
* URL : https://github.com/tidwall/match
* License : Expat
  Programming Lang: Go
  Description : simple string pattern matcher for Go

 Match is a very simple pattern matcher where '*' matches on any number
 characters and '?' matches on any one character.


This package is a dependency of the latest telegraf upstream release.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Maintainer changed.

Thanks,
Guillem


golang-github-tidwall-match_0.0~git20171002.1731857-0.1.debian.tar.xz
Description: application/xz

Bug#909141: RFP: golang-github-influxdata-go-syslog -- Go parser for syslog messages

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-go-syslog
  Version : 1.0.1-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/go-syslog
* License : Expat
  Programming Lang: Go
  Description : Go parser for syslog messages

 This package provides:
 • a RFC5424-compliant parser
 • a RFC5424-compliant builder
 • a RFC5425-compliant parser


This package is a dependency of the latest telegraf upstream release.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Maintainer changed.

Thanks,
Guillem


golang-github-influxdata-go-syslog_1.0.1-0.1.debian.tar.xz
Description: application/xz

Bug#909137: RFP: golang-github-influxdata-tail -- Go package for reading from continuously updated files (tail -f)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-tail
  Version : 1.0.0+git20180327.c434825-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/tail
* License : Expat
  Programming Lang: Go
  Description : Go package for reading from continuously updated files 
(tail -f)

Description: Go package for reading from continuously updated files (tail -f)
 tail is a Go library striving to emulate the features of the BSD tail
 program (like tail -f). It comes with full support for truncation/move
 detection as it is designed to work with log rotation tools.


This package is a required dependency for the latest telegraf upstream
release. This is a fork of the golang-github-hpcloud-tail that got
removed some time ago from the archive.

Attached the initial packaging. It requires filling the ITP bug number,
and setting proper Uploaders.

Thanks,
Guillem


golang-github-influxdata-tail_1.0.0+git20180327.c434825-0.1.debian.tar.xz
Description: application/xz

Bug#846614: RFP: golang-github-influxdata-wlog -- simple log level based Golang logger

[Guillem Jover]

Hi!

On Fri, 2016-12-02 at 17:26:34 +0100, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> Tags: patch
> Control: block 793749 by -1
> 
> * Package name: golang-github-influxdata-wlog
>   Version : 0.0~git20160411.0.7c63b0a-1
>   Upstream Author : InfluxData
> * URL : https://github.com/influxdata/wlog
> * License : MIT
>   Programming Lang: Go
>   Description : simple log level based Golang logger
> 
>  Provides an io.Writer that filters log messages based on a log level
>  prefix. Valid log levels are: DEBUG, INFO, WARN, ERROR, OFF.
> 
> 
> This package is a dependency of the new telegraf 1.1.1 upstream release.
> 
> Attached a working and tested packaging, where only the ITP bug number
> needs to be filled in the debian/changelog, and Maintainer changed.

Attached updated packaging.

Thanks,
Guillem


golang-github-influxdata-wlog_0.0~git20160411.0.7c63b0a-0.1.debian.tar.xz
Description: application/xz

Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

[Guillem Jover]

On Fri, 2018-07-20 at 02:18:51 +0200, Marco d'Itri wrote:
> On Jul 18, Marco d'Itri  wrote:
> > Some day it may replace crypt(3), currently provided by glibc:
> > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt

> I tried creating a package which would divert libc's libcrypt, but it 
> appears to be much harder than I thought.
> 
> Installing it would looke like:
> 
> 1) libcrypt1.preinst diverts glibc's libcrypt.so.1
> 2) dpkg does things
> 3) dpkg installs libxcrypt's libcrypt.so.1
> 4) dpkg does more things
> 5) libcrypt1.postinst runs/triggers ldconfig
> 
> And this means that perl (a libcrypt dependency) would be broken between 
> 1 and 5 (or maybe 1 and 3): is this ever going to work?

Given that this new package is going to replace a part of glibc, it
will need to behave as if it was part of the pseudo-Essential package
set. When it comes to the diversion that means it needs to be added
*without* the rename, so that we always have the libcrypt.so.1 present.

But otherwise why would it be broken?

> But even if this worked correctly, glibc installs a libcrypt-N.NN.so, 
> whose exact name I expect changes among different releases.

This one is tied to the major.minor glibc version, so I think you
should just ignore it. I'd expect at most glibc itself to perhaps rely
on it, anything else using it would not be very sane IMO.

Thanks,
Guillem

Bug#864358: ITP: bitfield -- bit array manipulation library

[Guillem Jover]

On Mon, 2017-08-14 at 01:41:43 +0900, Vitalie Ciubotaru wrote:
> On 08/06/2017 12:28 AM, Guillem Jover wrote:
> >
> > Well, obviously not entirely as complete but the BSDs (and libbsd
> > otherwise) do have something like .
> > 
> 
> The difference between sys/bitstring.h and the package I propose is that
> bitstring.h implements a bit array within one unit of data storage (unsigned
> char, 1 byte, 8 bits), while my package uses an array of units (array of
> unsigned long integers, usually 32 or 64 bits EACH). This means that BSD's bit
> array can't be longer that 8 bits, while mine is limited by memory size only.

Nope,  does support an unlimited amount of bits by using
arrays of unsigned chars. You might want to recheck its implementation. :)

> > BTW, I noticed when I checked the implementation that you are using
> > HAVE_BITFIELD_H as the header macro protector, but that's actually a
> > bad idea, as with the typical autoconf based build-system that macro
> > will already be defined if the build-system does something like
> > AC_CHECK_HEADERS([bitfield.h]), which means the contents will be
> > secluded.
> 
> Oh, yes, you are right. I was able to reproduce this problem. The name of the
> header guard needs to be changed. Thank you very much for pointing it out.

No problem!

Regards,
Guillem

Bug#864358: ITP: bitfield -- bit array manipulation library

[Guillem Jover]

Hi!

On Wed, 2017-06-07 at 23:13:33 +0900, Vitalie Ciubotaru wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Vitalie Ciubotaru 
> 
> * Package name: bitfield
>   Version : 0.6.3
>   Upstream Author : Vitalie Ciubotaru 
> * URL : https://github.com/ciubotaru/bitfield
> * License : GPL
>   Programming Lang: C
>   Description : bit array manipulation library
> 
> bitfield is a library of functions for creating, modifying and destroying bit
> fields (or bit arrays), i.e. series of zeroes and ones spread across an array 
> of
> storage units (unsigned long integers).
> 
> Bit array is a simple data structure used in a wide range of software 
> (starting
> from Linux kernel), yet there is no library that would provide this
> functionality, so every package has to reinvent the wheel.

Well, obviously not entirely as complete but the BSDs (and libbsd
otherwise) do have something like .

BTW, I noticed when I checked the implementation that you are using
HAVE_BITFIELD_H as the header macro protector, but that's actually a
bad idea, as with the typical autoconf based build-system that macro
will already be defined if the build-system does something like
AC_CHECK_HEADERS([bitfield.h]), which means the contents will be
secluded.

Thanks,
Guillem

Bug#859678: ITP: registration-agent -- standalone SIP registration utility

[Guillem Jover]

Hi!

[ I just noticed this ITP while going over the ftp-master's NEW queue
  web page. Please try to X-Debbugs-CC to d-d so that people can
  review these in the future! Thanks. ]

On Wed, 2017-04-05 at 22:16:34 +0200, Daniel Pocock wrote:
> Package: wnpp
> Severity: wishlist
> Owner: dan...@pocock.pro

> https://github.com/resiprocate/registration-agent
> 
> License: BSD-3

> Daemon process that sends SIP REGISTER requests, allowing the user to
> specify an arbitrary Contact header where incoming calls will be directed.
> 
> This is useful for people who want to send a REGISTER request to their
> ITSP telling it to send calls to their SIP proxy instead of a phone or
> Asterisk server.

I find the project and package name exceedingly generic for an
implementation of a thing that is very domain specific. Could you
try to get upstream to rename it to something else less generic?

Various namespaces in something like Debian are global resources that
affect all of us, and curating and preserving them in a meaningful way
is very important! :)

Thanks,
Guillem

Bug#851780: RFP: libinfluxdb-lineprotocol-perl -- write and read InfluxDB LineProtocol

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libinfluxdb-lineprotocol-perl
  Version : 1.008
  Upstream Author : Thomas Klausner 
* URL : https://metacpan.org/release/InfluxDB-LineProtocol
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : write and read InfluxDB LineProtocol

 The InfluxDB time series database (since version 0.9) uses a LineProtocol
 to write time series data into the database. InfluxDB::LineProtocol makes
 it possible to generate such a line from a data-structure, handling all
 the annoying escaping and sorting. It can also be used to parse a line
 (perhaps produced by other code) so that it can be further modified.


This package is useful when wanting to interact via Perl with an InfluxDB
instance.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, Version
bumper to a proper -1, and Vcs fields added if appropriate.

Thanks,
Guillem


libinfluxdb-lineprotocol-perl_1.008-0.1.debian.tar.xz
Description: application/xz

Bug#793749: ITP: telegraf -- plugin-driven server agent for reporting metrics into InfluxDB

[Guillem Jover]

Hey!

On Mon, 2016-10-17 at 23:47:23 +0200, Guillem Jover wrote:
> On Sun, 2015-07-26 at 23:32:17 -0400, Alexandre Viau wrote:
> > Package: wnpp
> > Severity: wishlist
> 
> > * Package name: telegraf
> >   Upstream Author : InfluxDB inc.
> > * URL : https://github.com/influxdb/telegraf
> > * License : Expat
> >   Programming Lang: Go

> Ok, all necessary parts have either bugs filed against existing packages
> in Debian, or RFP filed with packaging patches. And are blocking this
> bug.

I've now updated against the upstream 1.1.2, plus some packaging
cleanups and fixes. Filed additional RFPs needed (marked also as
blocking) or got required dependencies in Debian updated.

> Attached is a working and tested packaging delta against
> <https://anonscm.debian.org/cgit/pkg-go/packages/telegraf.git/>. The
> missing part is updating that repo to version 1.0.1, which is the
> latest upstream release, and what I've been working against. Please
> let me know if something smells fishy.

Same situation but against 1.1.2.

Thanks,
Guillem
From 2708ecc851abe62e482c98115a20e8d370a8 Mon Sep 17 00:00:00 2001
From: Guillem Jover <gjo...@sipwise.com>
Date: Mon, 17 Oct 2016 23:32:53 +0200
Subject: [PATCH] Update packaging to 1.1.2

---
 debian/.gitignore  |7 +
 debian/changelog   |   37 +-
 debian/control |  102 +-
 debian/copyright   |   11 +-
 .../excise-unavailable-plugins-in-debian.patch |   98 ++
 debian/patches/series  |3 +
 debian/patches/testsuite-no-network.patch  |   23 +
 debian/patches/use-licenseful-module.patch |   26 +
 debian/rules   |   39 +-
 debian/telegraf-dev.install|1 +
 debian/telegraf.conf   | 1456 
 debian/telegraf.dirs   |3 +
 debian/telegraf.init   |  121 ++
 debian/telegraf.install|2 +
 debian/telegraf.lintian-overrides  |3 +
 debian/telegraf.logrotate  |   10 +
 debian/telegraf.postinst   |   42 +
 debian/telegraf.postrm |   28 +
 18 files changed, 1979 insertions(+), 33 deletions(-)
 create mode 100644 debian/.gitignore
 create mode 100644 debian/patches/excise-unavailable-plugins-in-debian.patch
 create mode 100644 debian/patches/series
 create mode 100644 debian/patches/testsuite-no-network.patch
 create mode 100644 debian/patches/use-licenseful-module.patch
 create mode 100644 debian/telegraf-dev.install
 create mode 100644 debian/telegraf.conf
 create mode 100644 debian/telegraf.dirs
 create mode 100755 debian/telegraf.init
 create mode 100644 debian/telegraf.install
 create mode 100644 debian/telegraf.lintian-overrides
 create mode 100644 debian/telegraf.logrotate
 create mode 100644 debian/telegraf.postinst
 create mode 100644 debian/telegraf.postrm

diff --git a/debian/.gitignore b/debian/.gitignore
new file mode 100644
index ..30f7739e
--- /dev/null
+++ b/debian/.gitignore
@@ -0,0 +1,7 @@
+*.debhelper
+*.substvars
+*.log
+files
+tmp
+telegraf
+telegraf-dev
diff --git a/debian/changelog b/debian/changelog
index 24cf6077..92acea85 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,38 @@
-telegraf (0.1.8~dfsg1-1) UNRELEASED; urgency=low
+telegraf (1.1.2-0.1) UNRELEASED; urgency=low
 
-  * Initial release. (Closes: #XX)
+  [ Alexandre Viau ]
+  * Initial release. (Closes: #793749)
+
+  [ Guillem Jover ]
+  * New upstream release 1.1.2.
+- Update Build-Depends and telegraf-dev Depends.
+  * Fix SNMP plugin to build and pass the test suite.
+  * Fix test suite to avoid a flaky test.
+  * Run test suite in short mode, to skip tests that require running services.
+  * Use the github.com/kballard/go-shellquote module instead of
+github.com/gonuts/go-shellquote, which has no license as is not in Debian.
+  * Use dpkg Makefile fragments to get the upstream version, and set
+main.version with it.
+  * Use current import path, and switch from DH_GOPKG to XS-Go-Import-Path.
+  * Wrap and sort (-ast) debian/control fields.
+  * Add a Built-Using field to the telegraf binary.
+  * Change the Architecture field for telegraf from all to any.
+  * Set the builddirectory to build.
+  * Set DH_GOLANG_INSTALL_EXTRA to the list of required testdata files.
+  * Set DH_GOLANG_EXCLUDES to the plugins that pull dependencies not present
+in Debian, and that are peripheral. And disable those plugins from the
+code with a patch. They can be re-enabled once the dependencies get
+packaged in Debian.
+  * Use https in the debian/copyright Format field.
+  * Install a default 

Bug#846614: RFP: golang-github-influxdata-wlog -- simple log level based Golang logger

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-wlog
  Version : 0.0~git20160411.0.7c63b0a-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/wlog
* License : MIT
  Programming Lang: Go
  Description : simple log level based Golang logger

 Provides an io.Writer that filters log messages based on a log level
 prefix. Valid log levels are: DEBUG, INFO, WARN, ERROR, OFF.


This package is a dependency of the new telegraf 1.1.1 upstream release.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Maintainer changed.

Thanks,
Guillem


golang-github-influxdata-wlog_0.0~git20160411.0.7c63b0a-0.1.debian.tar.xz
Description: application/xz

Bug#840675: RFP: influxdb-relay -- basic high availability layer for InfluxDB

[Guillem Jover]

Hi!

On Thu, 2016-10-13 at 19:54:23 +0200, Guillem Jover wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: influxdb-relay
>   Version : 0.0~20160928.0.535181e
>   Upstream Author : InfluxData
> * URL : https://github.com/influxdata/influxdb-relay
> * License : Expat
>   Programming Lang: Go
>   Description : basic high availability layer for InfluxDB
> 
>   This daemon listens for InfluxDB requests and forwards them to one or
>   more InfluxDB servers, allowing to replicate for example writes requests
>   to multiple destinations.

> This package is helpful if you are deploying InfluxDB on a cluster
> and need some kind of basic replication and HA setup.
> 
> Attached a working and tested packaging patch (execept for the systemd
> service file), where only the ITP bug number needs to be filled in the
> debian/changelog, Maintainer changed, and Vcs fields added.

Updated patch against latest upstream, and several minor fixes to the
init script and packaging metadata.

Thanks,
Guillem
From 003fe691dd6a7cadb88440e005969156767da1ae Mon Sep 17 00:00:00 2001
From: Guillem Jover <gjo...@sipwise.com>
Date: Wed, 28 Sep 2016 16:24:34 +0200
Subject: [PATCH] Initial packaging

---
 debian/changelog   |   5 +
 debian/compat  |   1 +
 debian/control |  44 
 debian/copyright   |  32 ++
 ...lang-github-influxdb-influxdb-relay-dev.install |   1 +
 ...golang-github-influxdb-influxdb-relay-dev.links |   1 +
 debian/influxdb-relay.conf |  54 ++
 debian/influxdb-relay.dirs |   2 +
 debian/influxdb-relay.init | 120 +
 debian/influxdb-relay.install  |   2 +
 debian/influxdb-relay.lintian-overrides|   5 +
 debian/influxdb-relay.logrotate|   8 ++
 debian/influxdb-relay.manpages |   1 +
 debian/influxdb-relay.postinst |  44 
 debian/influxdb-relay.postrm   |  31 ++
 debian/influxdb-relay.service  |  16 +++
 debian/manpages/influxdb-relay.1   |  13 +++
 debian/rules   |  11 ++
 debian/source/format   |   1 +
 19 files changed, 392 insertions(+)
 create mode 100644 debian/changelog
 create mode 100644 debian/compat
 create mode 100644 debian/control
 create mode 100644 debian/copyright
 create mode 100644 debian/golang-github-influxdb-influxdb-relay-dev.install
 create mode 100644 debian/golang-github-influxdb-influxdb-relay-dev.links
 create mode 100644 debian/influxdb-relay.conf
 create mode 100644 debian/influxdb-relay.dirs
 create mode 100644 debian/influxdb-relay.init
 create mode 100644 debian/influxdb-relay.install
 create mode 100644 debian/influxdb-relay.lintian-overrides
 create mode 100644 debian/influxdb-relay.logrotate
 create mode 100644 debian/influxdb-relay.manpages
 create mode 100644 debian/influxdb-relay.postinst
 create mode 100644 debian/influxdb-relay.postrm
 create mode 100644 debian/influxdb-relay.service
 create mode 100644 debian/manpages/influxdb-relay.1
 create mode 100755 debian/rules
 create mode 100644 debian/source/format

diff --git a/debian/changelog b/debian/changelog
new file mode 100644
index 000..44d88f7
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,5 @@
+influxdb-relay (0.0~20161114.0.adaa2ea-1) UNRELEASED; urgency=medium
+
+  * Initial release. (Closes: #840675)
+
+ -- Guillem Jover <gjo...@sipwise.com>  Wed, 28 Sep 2016 14:21:32 +0200
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 000..ec63514
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+9
diff --git a/debian/control b/debian/control
new file mode 100644
index 000..c4d65d2
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,44 @@
+Source: influxdb-relay
+Section: database
+Priority: extra
+Homepage: https://github.com/influxdata/influxdb-relay
+Maintainer: Sipwise Development Team <supp...@sipwise.com>
+Build-Depends:
+ debhelper (>= 9),
+ dh-golang (>= 1.9),
+ golang-go,
+# Golang libraries below - Shared deps with dev package
+ golang-github-influxdb-influxdb-dev,
+ golang-github-naoina-go-stringutil-dev,
+ golang-github-naoina-toml-dev,
+Standards-Version: 3.9.8
+XS-Go-Import-Path: github.com/influxdata/influxdb-relay
+
+Package: golang-github-influxdb-influxdb-relay-dev
+Architecture: all
+Pre-Depends:
+ ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ golang-github-influxdb-influxdb-dev,
+ golang-github-naoina-go-stringutil-dev,
+ golang-github-naoina-toml-dev,
+Description: basic high availability layer for InfluxDB -- development files
+ This daemon listens for InfluxDB requests and forwards them 

Bug#793749: ITP: telegraf -- plugin-driven server agent for reporting metrics into InfluxDB

[Guillem Jover]

Hi!

On Mon, 2016-10-17 at 23:47:23 +0200, Guillem Jover wrote:
> On Sun, 2015-07-26 at 23:32:17 -0400, Alexandre Viau wrote:
> > Package: wnpp
> > Severity: wishlist
> 
> > * Package name: telegraf
> >   Upstream Author : InfluxDB inc.
> > * URL : https://github.com/influxdb/telegraf
> > * License : Expat
> >   Programming Lang: Go
> 
> Ok, all necessary parts have either bugs filed against existing packages
> in Debian, or RFP filed with packaging patches. And are blocking this
> bug.
> 
> Attached is a working and tested packaging delta against
> <https://anonscm.debian.org/cgit/pkg-go/packages/telegraf.git/>. The
> missing part is updating that repo to version 1.0.1, which is the
> latest upstream release, and what I've been working against. Please
> let me know if something smells fishy.

Attached an updated patch, that trims the delta with usptream. And
fixes some minor issues.

> For the patches needed for telegraf, I'll be submitting them upstream,
> but only once I've internally cleared the situation with the CLA.

I've started doing this now.

Thanks,
Guillem


0001-Update-packaging-to-1.0.1.patch.xz
Description: application/xz

Bug#841121: [pkg-go] Bug#841121: RFP: golang-github-influxdata-config -- unified configuration management package

[Guillem Jover]

Hi!

On Wed, 2016-10-19 at 02:06:03 +, Potter, Tim (HPE Linux Support) wrote:
> On 18 Oct 2016, at 6:06 AM, Guillem Jover <gjo...@sipwise.com> wrote:
> > Attached a working and tested packaging, where only the ITP bug number
> > needs to be filled in the debian/changelog, Maintainer changed, and Vcs
> > fields added.
> 
> I've uploaded this to a new packaging repo and it builds just fine.

Thanks!

> I took the liberty of setting the Maintainer to the team and uploaders to
> sipwise.  Feel free to revert if that's not what you want.

Yeah, I don't mind giving a hand when needed and doing sporadic
drive-by maintainership (as part of my work) but preferibly not
actual maintainership in Debian, that's why I filed RFPs instead
of ITPs. ;)

I don't think I've got write access to the pkg-go repos, so I'd
appreciate if you could remove the sipwise address from Uploaders
from those packages? Thanks!

Regards,
Guillem

Bug#841081: [pkg-go] Bug#841081: RFP: golang-gopkg-dancannon-gorethink.v1 -- RethinkDB driver for Go

[Guillem Jover]

Hi!

On Wed, 2016-10-19 at 01:40:02 +, Potter, Tim (HPE Linux Support) wrote:
> On 18 Oct 2016, at 1:21 AM, Guillem Jover <gjo...@sipwise.com> wrote:
> > Attached a working and tested packaging, where only the ITP bug number
> > needs to be filled in the debian/changelog. The other patch is required
> > to get the git repository back to a proper upstream version, because it
> > was at v2 now.
> 
> Which repo were you looking at for the first patch?  The one at 
> golang-gopkg-dancannon-gorethink.v1
> was never at v2.  Maybe there was a split into v1 and v2 but that could have
> happened before my time.

The repo I was working against was:

 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-dancannon-gorethink.v1.git

which does contain an import of the v2 branch version v2.0.1 into the
v1.4.1 tag. Take a look at commit 1ec608b3e9473da10b35ddfa5afc40a137df6f32
and you'll see.

> The second patch applies just fine.  I pushed it but the remark about
> changing the build directory to _build that Martin Ferrari made about
> golang-dns applies here as well.  Technically it could mess up
> multi-platform builds but I'm not aware of packages that do this.

My same reply applies here as well, I find it more pleasing to have
the same directory regardless of the host system, because it makes it
easier to debug, or instruct people to do so. It certainly should have
no visible effect to the build machinery, as long as there's no need
to explicitly point to files underneath the build directory, but I
think it's still better. But do as you prefer, or your group policies
dictate, I don't really mind. ;)

> I added a missing build-dependency (why does v1 of the package require v2?
> that's weird) and added a few tweaks.

It does not depend on v2, the problem is that it *is* v2, but the
package gets installed as v1 due to the "unmatched" XS-Go-Import-Path
field, so go cannot find the real module and complains that it's
missing. The reversion patch really needs to be applied. :) I guess
having the tag point to the incorrect contents will be confusing, but
fixing that would require rewriting history. Perhaps in this case it's
worth it, and instead of the patch, just rebasing and force pushing
might be better, up to you.

Thanks,
Guillem

Bug#793749: ITP: telegraf -- plugin-driven server agent for reporting metrics into InfluxDB

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sun, 2015-07-26 at 23:32:17 -0400, Alexandre Viau wrote:
> Package: wnpp
> Severity: wishlist

> * Package name: telegraf
>   Upstream Author : InfluxDB inc.
> * URL : https://github.com/influxdb/telegraf
> * License : Expat
>   Programming Lang: Go

Ok, all necessary parts have either bugs filed against existing packages
in Debian, or RFP filed with packaging patches. And are blocking this
bug.

Attached is a working and tested packaging delta against
<https://anonscm.debian.org/cgit/pkg-go/packages/telegraf.git/>. The
missing part is updating that repo to version 1.0.1, which is the
latest upstream release, and what I've been working against. Please
let me know if something smells fishy.

For the patches needed for telegraf, I'll be submitting them upstream,
but only once I've internally cleared the situation with the CLA.

Thanks,
Guillem
From cc6f2ab1a4f25530c46418edfb3eb79de2c67ce9 Mon Sep 17 00:00:00 2001
From: Guillem Jover <gjo...@sipwise.com>
Date: Mon, 17 Oct 2016 23:32:53 +0200
Subject: [PATCH] Update packaging to 1.0.1

---
 debian/.gitignore   |7 +
 debian/changelog|   35 +-
 debian/control  |   98 +-
 debian/copyright|   11 +-
 debian/patches/excise-unavailable-plugins.patch |   97 ++
 debian/patches/fix-snmp-plugin.patch|   33 +
 debian/patches/series   |4 +
 debian/patches/testsuite-no-network.patch   |  412 +++
 debian/patches/use-licenseful-module.patch  |   22 +
 debian/rules|   33 +-
 debian/telegraf-dev.install |1 +
 debian/telegraf.conf| 1456 +++
 debian/telegraf.dirs|3 +
 debian/telegraf.init|  121 ++
 debian/telegraf.install |2 +
 debian/telegraf.lintian-overrides   |3 +
 debian/telegraf.logrotate   |   10 +
 debian/telegraf.postinst|   42 +
 debian/telegraf.postrm  |   28 +
 19 files changed, 2387 insertions(+), 31 deletions(-)
 create mode 100644 debian/.gitignore
 create mode 100644 debian/patches/excise-unavailable-plugins.patch
 create mode 100644 debian/patches/fix-snmp-plugin.patch
 create mode 100644 debian/patches/series
 create mode 100644 debian/patches/testsuite-no-network.patch
 create mode 100644 debian/patches/use-licenseful-module.patch
 create mode 100644 debian/telegraf-dev.install
 create mode 100644 debian/telegraf.conf
 create mode 100644 debian/telegraf.dirs
 create mode 100755 debian/telegraf.init
 create mode 100644 debian/telegraf.install
 create mode 100644 debian/telegraf.lintian-overrides
 create mode 100644 debian/telegraf.logrotate
 create mode 100644 debian/telegraf.postinst
 create mode 100644 debian/telegraf.postrm

diff --git a/debian/.gitignore b/debian/.gitignore
new file mode 100644
index 000..30f7739
--- /dev/null
+++ b/debian/.gitignore
@@ -0,0 +1,7 @@
+*.debhelper
+*.substvars
+*.log
+files
+tmp
+telegraf
+telegraf-dev
diff --git a/debian/changelog b/debian/changelog
index f7377c4..dff214e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,38 @@
-telegraf (0.1.8~dfsg1-1) UNRELEASED; urgency=low
+telegraf (1.0.1-1) UNRELEASED; urgency=low
 
+  [ Alexandre Viau ]
   * Initial release. (Closes: #793749)
 
+  [ Guillem Jover ]
+  * New upstream release 1.0.1.
+- Update Build-Depends and telegraf-dev Depends.
+  * Fix SNMP plugin to build and pass the test suite.
+  * Fix test suite to avoid a flaky test, and to not assume service daemons
+are running by keying on a new environment variable TELEGRAF_SERVERS_TEST,
+which we do not set.
+  * Use the github.com/kballard/go-shellquote module instead of
+github.com/gonuts/go-shellquote, which has no license as is not in Debian.
+  * Use dpkg Makefile fragments to get the upstream version, and set
+main.version with it.
+  * Use current import path, and switch from DH_GOPKG to XS-Go-Import-Path.
+  * Wrap and sort (-ast) debian/control fields.
+  * Add a Built-Using field to the telegraf binary.
+  * Change the Architecture field for telegraf from all to any.
+  * Set the builddirectory to build.
+  * Set DH_GOLANG_INSTALL_EXTRA to the list of required testdata files.
+  * Set DH_GOLANG_EXCLUDES to the plugins that pull dependencies not present
+in Debian, and that are peripheral. And disable those plugins from the
+code with a patch. They can be re-enabled once the dependencies get
+packaged in Debian.
+  * Use https in the debian/copyright Format field.
+  * Install a default telegraf configuration file.
+  * Install a logrotate file for telegraf.
+  * Create postinst and prerm maintaner scripts to handle crea

Bug#841121: RFP: golang-github-influxdata-config -- unified configuration management package

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-config
  Version : 0.0~git20160309.0.8ec4638-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/config
* License : NONE!? 
  Programming Lang: Go
  Description : A unified configuration management package

 The intention of this package is to unify existing patterns of interacting
 with configuration across the elements of the TICK+E stack. As such, it
 implements the superset of APIs from both github.com/influxdata/toml and
 github.com/BurntSushi/toml, while also providing a small API for the common
 case of loading and storing configuration from a particular file. It also
 provides wrapper types for formatting Durations and Sizes in TOML, which
 were previously held in a sub-package within InfluxDB. Also provided is the
 ability to document configuration fields using a "doc" struct tag. When the
 config struct is marshalled as TOML, any doc struct tags found will be
 inserted as TOML comments in an appropriate place to document the
 corresponding field.


This package is a dependency of telegraf latest upstream releases.

The lack of license situation needs to be resolved before this can be
uploaded (see the link in the License field above).

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and Vcs
fields added.

Thanks,
Guillem


golang-github-influxdata-config_0.0~git20160309.0.8ec4638-1.debian.tar.xz
Description: application/xz

Bug#841120: RFP: golang-github-influxdata-toml -- TOML parser and encoder library for Golang

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-toml
  Version : 0.0~git20160905.0.ad49a5c-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/toml
* License : Expat
  Programming Lang: Go
  Description : TOML parser and encoder library for Golang

 This is the Influxdata fork of the official TOML package. It supports
 additional data types, documenting TOML fields, and nicer output.


This package is a dependency of telegraf latest upstream releases.

There are two problems to be solved before this can be uploaded:

  * Uses a pre-built generated PEG output file, should be switched to
use the newly packaged peg-go.
  * Upstream has modified directly the pre-built generated PEG output
file, tracked at ,
but ITSM those changes could simply be dropped when the pre-generated
file gets dropped.

Attached a working and tested packaging, where in addition to the above,
only the ITP bug number needs to be filled in the debian/changelog,
Maintainer changed, and Vcs fields added.

Thanks,
Guillem


golang-github-influxdata-toml_0.0~git20160905.0.ad49a5c-1.debian.tar.xz
Description: application/xz

Bug#841081: RFP: golang-gopkg-dancannon-gorethink.v1 -- RethinkDB driver for Go

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-gopkg-dancannon-gorethink.v1
  Version : 1.4.1
  Upstream Author : Daniel Cannon <dan...@danielcannon.co.uk>
* URL : https://github.com/dancannon/gorethink
* License : Apache-2.0
  Programming Lang: Go
  Description : RethinkDB driver for Go

 RethinkDB >= 2.0 compatible driver. The driver uses a connection
 pool at all times, by default it creates and frees connections
 automatically. It's safe for concurrent use by multiple goroutines.


This package is a dependency of telegraf latest upstream releases, it
was already in the archive but got removed due to being unused. See
<https://bugs.debian.org/829277>.


Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog. The other patch is required
to get the git repository back to a proper upstream version, because it
was at v2 now.

Thanks,
Guillem
From a0006f79e905db75aeb673ff08344ba3fc3dfa17 Mon Sep 17 00:00:00 2001
From: Guillem Jover <gjo...@sipwise.com>
Date: Mon, 17 Oct 2016 13:59:45 +0200
Subject: [PATCH 1/2] Revert import of v2.0.1 back to v1.4.1

---
 .travis.yml   |   2 -
 CHANGELOG.md  |  40 
 README.md |  33 +--
 checkers_test.go  |   2 +-
 cluster.go|  43 ++--
 connection.go |  20 +-
 connection_handshake.go   | 450 --
 connection_helper.go  |  55 -
 cursor.go | 262 +++---
 cursor_test.go|  86 
 doc.go|   2 +-
 encoding/encoder_test.go  |  23 --
 encoding/encoder_types.go |  69 ++
 errors.go |   2 +-
 example_query_aggregation_test.go |  30 +--
 gorethink.go  |   2 +-
 gorethink_test.go |   4 +
 node.go   |   2 +-
 pseudotypes.go|   2 +-
 ql2/ql2.pb.go |  15 +-
 ql2/ql2.proto |  15 +-
 query.go  |  28 +--
 query_admin.go|  12 +-
 query_admin_test.go   |  32 +--
 query_aggregation.go  |  44 +---
 query_aggregation_test.go |  41 +---
 query_control.go  |   2 +-
 query_db.go   |   2 +-
 query_geospatial.go   |   2 +-
 query_geospatial_test.go  |   2 +-
 query_join.go |   5 +-
 query_join_test.go|   7 +-
 query_manipulation.go |   2 +-
 query_math.go |   2 +-
 query_select.go   |   2 +-
 query_select_test.go  |  12 +-
 query_string.go   |   2 +-
 query_table.go|   4 +-
 query_table_test.go   |   1 +
 query_test.go |  17 --
 query_time.go |   2 +-
 query_transformation.go   |  23 +-
 query_write.go|   3 +-
 session.go|  11 +-
 session_test.go   |  58 +
 utils.go  |   5 +-
 46 files changed, 270 insertions(+), 1210 deletions(-)
 delete mode 100644 connection_handshake.go

diff --git a/.travis.yml b/.travis.yml
index 342c4db..2870132 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -6,8 +6,6 @@ go:
 
 cache: apt
 
-go_import_path: gopkg.in/dancannon/gorethink.v2
-
 before_script:
   - source /etc/lsb-release && echo "deb http://download.rethinkdb.com/apt $DISTRIB_CODENAME main" | sudo tee /etc/apt/sources.list.d/rethinkdb.list
   - wget -qO- http://download.rethinkdb.com/apt/pubkey.gpg | sudo apt-key add -
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1d1aaae..0ac94f1 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,46 +2,6 @@
 All notable changes to this project will be documented in this file.
 This project adheres to [Semantic Versioning](http://semver.org/).
 
-## v2.0.1 - 2016-04-14
-
-### Added
- - Added `UnionWithOpts` term which allows `Union` to be called with optional arguments (such as `Interleave`)
- - Added `IncludeOffsets` and `IncludeTypes` optional arguments to `ChangesOpts`
- - Added `Conflict` optional argument to `InsertOpts`
-
-### Fixed
- - Fixed error when connecting to database as non-admin user, please note that `DiscoverHosts` will not work with user authentication at this time due to the fact that RethinkDB restricts access to the required system tables.
-
-## v2.0.0 - 2016-04-13
-
-### Changed
-
- - GoRethink now uses the v1.0 RethinkDB protocol which supports RethinkDB v2.3 and above. If you are using RethinkDB 2.2 or older please set `HandshakeVersion` when creating a session. For example:
-```go
-r.Connect(
-...
-HandshakeVersion: r.Hands

Bug#840766: RFP: golang-github-pointlander-peg -- Peg, Parsing Expression Grammar for GoLang

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-pointlander-peg
  Version : 0.0~git20160904.0.58700b-1
  Upstream Author : Andrew Snodgrass 
* URL : https://github.com/pointlander/peg
* License : BSD-3-clause
  Programming Lang: Go
  Description : Peg, Parsing Expression Grammar for GoLang

 An implementation of a Packrat parser generator. A Packrat parser is a
 descent recursive parser capable of backtracking. The generated parser
 searches for the correct parsing of the input.


This is a currently missing build dependency of golang-github-naoina-toml
source package. Which is thus unfit for Debian main as it stands.

Thanks,
Guillem

Bug#840759: RFP: golang-github-soniah-gosnmp -- SNMP library written in GoLang

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-soniah-gosnmp
  Version : 1.9-memory+git20160925.103.3fe3beb-1
  Upstream Author : Sonia Hamilton
* URL : https://github.com/soniah/gosnmp
* License : BSD-3-clause
  Programming Lang: Go
  Description : SNMP library written in GoLang

 GoSNMP is an SNMP client library fully written in Go. It provides Get,
 GetNext, GetBulk, Walk, BulkWalk, Set and Traps. It supports IPv4
 and IPv6, using SNMPv2c or SNMPv3.


This package is a dependency of telegraf latest upstream releases.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and Vcs
fields added.

Thanks,
Guillem


golang-github-soniah-gosnmp_1.9-memory+git20160925.103.3fe3beb-1.debian.tar.xz
Description: application/xz

Bug#840747: RFP: golang-github-vjeantet-grok -- simple library to use/parse grok patterns with go

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-vjeantet-grok
  Version : 0.0~git20160427.0.83bfdfd-1
  Upstream Author : Valere JEANTET
* URL : https://github.com/vjeantet/grok
* License : Apache-2.0
  Programming Lang: Go
  Description : simple library to use/parse grok patterns with go

 This package contains a set of predefined patterns, but custom
 patterns can also be added.


This package is a dependency of telegraf latest upstream releases.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and Vcs
fields added.

Thanks,
Guillem


golang-github-vjeantet-grok_0.0~git20160427.0.83bfdfd-1.debian.tar.xz
Description: application/xz

Bug#840742: RFP: golang-github-kardianos-service -- Run go programs as a service on major platforms

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-kardianos-service
  Version : 0.0~git20160824.0.7a88211-1
  Upstream Author : Daniel Theophanes
* URL : https://github.com/kardianos/service
* License : zlib
  Programming Lang: Go
  Description : Run go programs as a service on major platforms

 service will install / un-install, start / stop, and run a program as a
 service (daemon). Currently supports Linux/(systemd | Upstart | SysV),
 OSX/Launchd and Windows XP+.
 .
 Windows controls services by setting up callbacks that are non-trivial. This
 is very different than other systems. This package provides the same API
 despite the substantial differences. It also can be used to detect how a
 program is called, from an interactive terminal or from a service manager.


This package is a dependency of telegraf latest upstream releases.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and Vcs
fields added.

Thanks,
Guillem


golang-github-kardianos-service_0.0~git20160824.0.7a88211-1.debian.tar.xz
Description: application/xz

Bug#840676: [pkg-go] Bug#840676: RFP: golang-github-kardianos-osext -- Extensions to the standard "os" package

[Guillem Jover]

Control: reassign -1 golang-github-kardianos-osext-dev
Control: retitle -1 golang-osext: Packaging cleanups and new upstream release
Control: found -1 0.0~git20151222.0.29ae4ff-1

On Thu, 2016-10-13 at 20:25:11 +, Potter, Tim (HPE Linux Support) wrote:
> On 14 Oct 2016, at 5:44 AM, Guillem Jover <gjo...@sipwise.com> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Tags: patch
> > 
> > * Package name: golang-github-kardianos-osext
> >  Version : 0.0~git20160811.0.c2c54e5-1
> >  Upstream Author : Daniel Theophanes
> > * URL : https://github.com/kardianos/osext
> > * License : BSD-3-clause
> >  Programming Lang: Go
> >  Description : Extensions to the standard "os" package

> Hi Guillem.  This package is already in Debian under the source package name
> "golang-osext".  It's not the latest version though, so there is still some 
> work
> that can be done here.

Ah right, sorry, should have been looking for the binary package name
instead. Ok, then let's convert this into a bug against that package,
as cleanups and a request for a new upstream. :)

Attached the new diff.

(I've also renamed the Vcs field values, but those would need intervention
on alioth. :)

(Also, I noticed the choice of licensing for debian/* and while everyone
is obviously free to choose whatever they like, this kind of divergence
could create problematic siutation when adding local patches, as those
might not be acceptable to upstream for example.)

Thanks,
Guillem
diff -Naur golang-osext-0.0~git20151222.0.29ae4ff/debian/changelog golang-github-kardianos-osext/debian/changelog
--- golang-osext-0.0~git20151222.0.29ae4ff/debian/changelog	2016-04-30 17:19:42.0 +0200
+++ golang-github-kardianos-osext/debian/changelog	2016-10-14 13:13:32.373644305 +0200
@@ -1,3 +1,16 @@
+golang-github-kardianos-osext (0.0~git20160811.0.c2c54e5-1) UNRELEASED; urgency=medium
+
+  * New upstream version 0.0~git20160811.0.c2c54e5
+  * Use https URL in debian/copyright Format field.
+  * Add a Built-Using field.
+  * Remove unused shlibs:Depends substvar from Depends field.
+  * Remove redundant DH_GOPKG from debian/rules.
+  * Use _build as build directory.
+  * Rename source package name to match current Go packaging policy, as this
+should not require going via NEW.
+
+ -- Guillem Jover <gjo...@sipwise.com>  Fri, 14 Oct 2016 13:07:09 +0200
+
 golang-osext (0.0~git20151222.0.29ae4ff-1) unstable; urgency=medium
 
   [ Tim Potter ]
diff -Naur golang-osext-0.0~git20151222.0.29ae4ff/debian/control golang-github-kardianos-osext/debian/control
--- golang-osext-0.0~git20151222.0.29ae4ff/debian/control	2016-04-30 17:08:51.0 +0200
+++ golang-github-kardianos-osext/debian/control	2016-10-14 13:12:59.197481432 +0200
@@ -1,4 +1,4 @@
-Source: golang-osext
+Source: golang-github-kardianos-osext
 Section: devel
 Priority: extra
 Maintainer: Debian Go Packaging Team <pkg-go-maintain...@lists.alioth.debian.org>
@@ -6,13 +6,14 @@
 Build-Depends: debhelper (>= 9), dh-golang, golang-go
 Standards-Version: 3.9.8
 Homepage: https://github.com/kardianos/osext
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-go/packages/golang-osext.git
-Vcs-Git: https://anonscm.debian.org/git/pkg-go/packages/golang-osext.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-kardianos-osext.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-go/packages/golang-github-kardianos-osext.git
 XS-Go-Import-Path: github.com/kardianos/osext
 
 Package: golang-github-kardianos-osext-dev
 Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${misc:Depends}
+Built-Using: ${misc:Built-Using}
 Description: Extensions to the Go "os" package
  Go library implementing functions for discovering the current
  executable and folder to re-invoke the currently running program.
diff -Naur golang-osext-0.0~git20151222.0.29ae4ff/debian/copyright golang-github-kardianos-osext/debian/copyright
--- golang-osext-0.0~git20151222.0.29ae4ff/debian/copyright	2016-01-15 09:35:27.0 +0100
+++ golang-github-kardianos-osext/debian/copyright	2016-10-14 13:05:39.991237753 +0200
@@ -1,6 +1,6 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: osext
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Source: https://github.com/kardianos/osext
+Upstream-Name: osext
 
 Files: *
 Copyright: 2012 The Go Authors
diff -Naur golang-osext-0.0~git20151222.0.29ae4ff/debian/rules golang-github-kardianos-osext/debian/rules
--- golang-osext-0.0~git20151222.0.29ae4ff/debian/rules	2016-01-15 09:17:13.0 +0100
+++ golang-github-kardianos-osext/debian/rules	2016-10-14 13:08:43.956201246 +0200
@@ -1,6 +1,4 @@
 #!/usr/bin/make -f
 
-export DH_GOPKG := github.com/kardianos/osext
-
 %:
-	dh $@ --buildsystem=golang --with=golang
+	dh $@ --buildsystem=golang --with=golang --builddirectory=_build

Bug#840676: RFP: golang-github-kardianos-osext -- Extensions to the standard "os" package

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-kardianos-osext
  Version : 0.0~git20160811.0.c2c54e5-1
  Upstream Author : Daniel Theophanes
* URL : https://github.com/kardianos/osext
* License : BSD-3-clause
  Programming Lang: Go
  Description : Extensions to the standard "os" package

 There is sometimes utility in finding the current executable file that is
 running. This can be used for upgrading the current executable or finding
 resources located relative to the executable file. Both working directory
 and the os.Args[0] value are arbitrary and cannot be relied on; os.Args[0]
 can be "faked".


This package is a dependency of golang-github-kardianos-service, which
is a dependency of latest telegraf upstream releases.

Attached a working and tested packaging. It only requires filling in
this ITP bug number in debian/changelog, changing the Maintainer field
and adding Vcs fields.

Thanks,
Guillem


golang-github-kardianos-osext_0.0~git20160811.0.c2c54e5-1.debian.tar.xz
Description: application/xz

Bug#840675: RFP: influxdb-relay -- a basic high availability layer for InfluxDB

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: influxdb-relay
  Version : 0.0~20160928.0.535181e
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/influxdb-relay
* License : Expat
  Programming Lang: Go
  Description : a basic high availability layer for InfluxDB

  This daemon listens for InfluxDB requests and forwards them to one or
  more InfluxDB servers, allowing to replicate for example writes requests
  to multiple destinations.


This package is helpful if you are deploying InfluxDB on a cluster
and need some kind of basic replication and HA setup.

Attached a working and tested packaging patch (execept for the systemd
service file), where only the ITP bug number needs to be filled in the
debian/changelog, Maintainer changed, and Vcs fields added.

Thanks,
Guillem
From 4701fbd59906b3f12868f2fd40d8a46dbe02ac6e Mon Sep 17 00:00:00 2001
From: Guillem Jover <gjo...@sipwise.com>
Date: Wed, 28 Sep 2016 16:24:34 +0200
Subject: [PATCH] Initial packaging

---
 debian/changelog   |   5 +
 debian/compat  |   1 +
 debian/control |  44 
 debian/copyright   |  32 ++
 ...lang-github-influxdb-influxdb-relay-dev.install |   1 +
 ...golang-github-influxdb-influxdb-relay-dev.links |   1 +
 debian/influxdb-relay.conf |  54 ++
 debian/influxdb-relay.dirs |   2 +
 debian/influxdb-relay.init | 120 +
 debian/influxdb-relay.install  |   2 +
 debian/influxdb-relay.lintian-overrides|   5 +
 debian/influxdb-relay.logrotate|   8 ++
 debian/influxdb-relay.manpages |   1 +
 debian/influxdb-relay.postinst |  44 
 debian/influxdb-relay.postrm   |  31 ++
 debian/influxdb-relay.service  |  16 +++
 debian/manpages/influxdb-relay.1   |  13 +++
 debian/rules   |  12 +++
 debian/source/format   |   1 +
 19 files changed, 393 insertions(+)
 create mode 100644 debian/changelog
 create mode 100644 debian/compat
 create mode 100644 debian/control
 create mode 100644 debian/copyright
 create mode 100644 debian/golang-github-influxdb-influxdb-relay-dev.install
 create mode 100644 debian/golang-github-influxdb-influxdb-relay-dev.links
 create mode 100644 debian/influxdb-relay.conf
 create mode 100644 debian/influxdb-relay.dirs
 create mode 100644 debian/influxdb-relay.init
 create mode 100644 debian/influxdb-relay.install
 create mode 100644 debian/influxdb-relay.lintian-overrides
 create mode 100644 debian/influxdb-relay.logrotate
 create mode 100644 debian/influxdb-relay.manpages
 create mode 100644 debian/influxdb-relay.postinst
 create mode 100644 debian/influxdb-relay.postrm
 create mode 100644 debian/influxdb-relay.service
 create mode 100644 debian/manpages/influxdb-relay.1
 create mode 100755 debian/rules
 create mode 100644 debian/source/format

diff --git a/debian/changelog b/debian/changelog
new file mode 100644
index 000..eb775b4
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,5 @@
+influxdb-relay (0.0~20160928.0.535181e-1) UNRELEASED; urgency=medium
+
+  * Initial release. (Closes: #NN)
+
+ -- Guillem Jover <gjo...@sipwise.com>  Wed, 28 Sep 2016 14:21:32 +0200
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 000..ec63514
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+9
diff --git a/debian/control b/debian/control
new file mode 100644
index 000..609b68f
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,44 @@
+Source: influxdb-relay
+Section: database
+Priority: extra
+Homepage: https://github.com/influxdata/influxdb-relay
+Maintainer: Sipwise Development Team <supp...@sipwise.com>
+Build-Depends:
+ debhelper (>= 9),
+ dh-golang (>= 1.9),
+ golang-go,
+# Golang libraries below - Shared deps with dev package
+ golang-github-influxdb-influxdb-dev,
+ golang-github-naoina-go-stringutil-dev,
+ golang-github-naoina-toml-dev,
+Standards-Version: 3.9.8
+
+Package: golang-github-influxdb-influxdb-relay-dev
+Architecture: all
+Pre-Depends:
+ ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ golang-github-influxdb-influxdb-dev,
+ golang-github-naoina-go-stringutil-dev,
+ golang-github-naoina-toml-dev,
+Built-Using: ${misc:Built-Using}
+Description:  a basic high availability layer for InfluxDB -- development files
+ This daemon listens for InfluxDB requests and forwards them to one or
+ more InfluxDB servers, allowing to replicate for example writes requests
+ to multiple destination InfluxDB servers.
+ .
+ This is the development package.
+
+Package: influxdb-relay
+Architecture: any
+Depends:
+ ${shlibs:Depends},
+ ${misc:Depends},
+ lsb-base (>= 3.0-

Bug#840633: RFP: golang-github-retailnext-hllpp -- HyperLogLog++ cardinality estimation algorithm

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-retailnext-hllpp
  Version : 0.0~git20160427.0.83bfdfd-1
  Upstream Author : RetailNext, Inc.
* URL : https://github.com/retailnext/hllpp
* License : BSD-3-clause
  Programming Lang: Go
  Description : HyperLogLog++ cardinality estimation algorithm

 hllpp is an implementation of the HyperLogLog++ cardinality estimation
 algorithm in go. It optimizes for memory usage over CPU usage. It
 implements all the HyperLogLog optimizations introduced in the
 HyperLogLog++ paper (http://goo.gl/Z5Sqgu). Some notable features include:
 .
  * Marshaling so you can serialize to your datastore,
  * Extra space savings by only using 5 bits per register when possible,
  * Built-in non-streaming murmur3 implementation for fast hashing of input
data.


This package is required by the latest influxdb upstream. Attached tested
packaging, which only needs the ITP bug filled in debian/changelog,
Maintainer field changed, and Vcs fields added.

Thanks,
Guillem


golang-github-retailnext-hllpp.debian.tar.xz
Description: application/xz

Bug#840626: RFP: golang-github-eapache-go-xerial-snappy -- Xerial-compatible Snappy framing support for golang

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-eapache-go-xerial-snappy
  Version : 0.0~git20160609.0.bb955e0-1
  Upstream Author : Evan Huus
* URL : https://github.com/eapache/go-xerial-snappy
* License : MIT
  Programming Lang: Go
  Description : Xerial-compatible Snappy framing support for golang

 Packages using Xerial for snappy encoding use a framing format
 incompatible with basically everything else in existence. This package
 wraps Go's built-in snappy package to support it.


This is a requirement for new usptream releases of
golang-github-shopify-sarama (>= 1.10.x), which is a requirement for
packaging telegraf (its latest versions).

Tested and working packaging attached. Just needs filling in the ITP
bug number in the changelog, changing the Maintainer, and possibly
adding the Vcs fields.

Thanks,
Guillem


golang-github-eapache-go-xerial-snappy.debian.tar.xz
Description: application/xz

Bug#827678: ITP: pacapt -- Arch's pacman-like package manager for some Unices

[Guillem Jover]

Hi!

On Sun, 2016-06-19 at 23:44:50 +0800, ChangZhuo Chen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "ChangZhuo Chen (陳昌倬)" 

> * Package name: pacapt
>   Version : 2.3.8
>   Upstream Author : Anh K. Huynh
> * URL : https://github.com/icy/pacapt
> * License : Fair

That license is pretty much non-free, as it does not allow
modification nor redistribution, only using the code.

>   Programming Lang: Bash
>   Description : Arch's pacman-like package manager for some Unices
> 
>  pacapt is an Arch's pacman-like package manager for some Unices. It is
>  a bash script provides a wrapper for system's package manager.

Thanks,
Guillem

Bug#824130: ITP: libgames-support -- Useful functionality shared among GNOME games

[Guillem Jover]

Hi!

On Thu, 2016-05-12 at 17:39:57 +0200, Michael Biebl wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Michael Biebl 
> 
> * Package name: libgames-support
>   Version : 1.0.2
>   Upstream Author : Michael Catanzaro 
> * URL : https://wiki.gnome.org/Apps/Games
> * License : LGPL-3+
>   Programming Lang: Vala
>   Description : Useful functionality shared among GNOME games
> 
> Code shared between GNOME games.
> 
> This package will be maintained with the pkg-gnome team.

Hmm that's a very unfortunate and generic name for a project that is
apparently GNOME-specific? Of course other desktops, such as KDE have
committed the same sin but… :(

Thanks,
Guillem

Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs

[Guillem Jover]

Hi!

On Sat, 2016-04-30 at 21:57:47 +1000, Brian May wrote:
> Would appreciate it if somebody could confirm that the license is BSD
> and if so what version of the BSD license this is.
> 
> https://github.com/mkdocs/mkdocs-bootswatch/blob/master/LICENSE

That looks like a BSD-2 clause license but w/o the clauses itemized.
Of course BSD-style licenses have slight text variations in their
warranty and liability paragraph, but this one seems one of the
common ones that I've seen.

Thanks,
Guillem

Bug#821066: ITP: glide -- Vendor package management for golang

[Guillem Jover]

Hi!

On Fri, 2016-04-15 at 13:34:37 +0800, ChangZhuo Chen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "ChangZhuo Chen (陳昌倬)" 
> 
> * Package name: glide

There is already an unrelated glide source package in the archive.
Which also generates several *glide* binary packages. Namespacing
this one would seem like a good idea.

>   Version : 0.10.2
>   Upstream Author : Copyright (C) 2014-2016, Matt Butcher and Matt
> Copyright (C) 2016, Hewlett Packard Enterprise 
> Development LP
> Copyright (C) 2015, Google
> * URL : http://www.example.org/
> * License : Expat
>   Programming Lang: golang
>   Description : Vendor package management for golang
> 
>  Manage your vendor and vendored packages with ease. Glide is a tool for
>  managing the vendor directory within a Go package. This feature, first
>  introduced in Go 1.5, allows each package to have a vendor directory
>  containing dependent packages for the project. These vendor packages
>  can be installed by a tool (e.g. glide), similar to go get or they can
>  be vendored and distributed with the package.

Thanks,
Guillem