Bug#1063829: ITP: tftp-proxy -- proxy to redirect TFTP requests to HTTP

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian.a...@manchmal.in-ulm.de

* Package name: tftp-proxy
  Version : 1.0.0
  Upstream Contact: Arnoud Vermeer 
* URL : https://github.com/openfibernet/tftp-proxy
* License : Apache-2.0
  Programming Lang: Go
  Description : A TFTP server that proxies request to an HTTP
backend if a file is not found.

 This program is basically a minimalistic TFTP server. As an extra
 however, it will forward request that cannot be served to a
 configurable HTTP backend.
 .
 This is useful in a network where the actual TFTP server is relatively
 far away: Due to the simple design of TFTP, already 40ms of latency
 result in a very poor performance, tftp-proxy can shortcut that to
 network speed.
 .
 Additionally, the requests may be directed to a caching HTTP server.



signature.asc
Description: PGP signature

Bug#977716: RFP: llhttp -- parser for HTTP messages

[Christoph Biedl]

Control: retitle 977716 ITP: llhttp -- parser for HTTP messages
Control: tags 977716 pending

Christoph Biedl wrote...

> * Package name: llhttp
>   Version : 3.0.0

9.3.1 already

> The http-parser library has declared unmaintained by upstream[1],
> and this one here suggested as a solution to migrate to. Although
> probably not a simple drop-in replacement, Debian should abandon
> http-parser in favour of that one here in the long run.
>
> However, I do not wish to do the maintainership on my own. There's a lot
> of node.js involved, an area I don't feel competent do deal with.

As first projects have started migrating but nobody else has stepped up
in the past three years, and - last but not least - this seems doable ...
will take this package, still wouldn't mind if anybody else volunteers
for it.

Christoph


signature.asc
Description: PGP signature

Bug#1052683: ITP: railway -- GUI application for searching train journeys

[Christoph Biedl]

Arnaud Ferraris wrote...

> * Package name: railway
>   Version : 2.0.0
>   Upstream Contact: Julian Schmidhuber 
> * URL : https://gitlab.com/schmiddi-on-mobile/railway
> * License : GPL
>   Programming Lang: Rust
>   Description : GUI application for searching train journeys
>
> Railway is a graphical application allowing one to look up travel information
> for many different railways, all without needing to navigate through different
> websites.

As Deutsche Bahn is currently disimproving their timetable website big
scale, I'm quite interested in having this. Let me know if you're
looking for testers.

And aside, if you happen to bump into upstream, it would be great if
that application could honor $https_proxy, or allow running behind a
proxy by other means - using tsocks as a soxifier didn't work. And I
could use an export of a selected journey in some machine-readable
format.

Christoph


signature.asc
Description: PGP signature

Bug#1052421: ITP: control -- Python Control Systems Library

[Christoph Biedl]

Kurva Prashanth wrote...

> * Package name: control
>   Version : 0.9.4
>   Upstream Author :  >
> * URL : http://python-control.org/

While I cannot judge whether this package is a sensible addition to
Debian - I strongly ask you to re-consider the package name as "control"
can apply to many different areas, and is therefore not helping when
trying to figure if that package helps in a particular situation.
Also, as there's the debian/control file in each source package, this
will create some confusion and possibly even to users asking you for
help with their packaging.

Just from the above website, perhaps something like
python-feedback-control-systems or a bit shorter variant would be more
appropriate. I might be wrong.

Christoph


signature.asc
Description: PGP signature

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Christoph Biedl]

Varac wrote...

> * Package name: yq
>   Version : 2.1.2
>   Upstream Author : Mike Farah 
> * URL : http://mikefarah.github.io/yq/

Hello everybody,

it's been a while ... bookworm freeze is getting closer, and I'd like to
find a solution for the current problems providing an "yq" program to
handle yaml documents.

To sum it up:

* This ITP originally was about an implementation in Go ("go", by
  mikefarah)
  Pros:
  + (Possibly) faster
  + The first one in this thread
* There is another implementation in pure Python ("python", by kislyuk)
  Pros:
  + Simple
  + By design behaviour identical to jq
* The respective upstream are not willing to resolve the name clash

In the meantime, there is a new player around, called "fq"
, a somewhat Swiss army knife wrt
supported formats. Written in Go as well, it is available in bookworm.
Backporting to bullseye is at least not trivial.


Now my main interest was to have something as /usr/bin/yq, not just for
me but for everybody.

Ideas:

1. Co-existence

Debian ships both variants but with different binary names like "yq-go",
"yq-python" or "yq-mikefarah" and "yq-kislyuk". Using Debian's
alternatives system, user can set their preferred variant.

Pros:
+ Provides all flavours

Cons:
- Maintainance overhead
- Users might be confused because /usr/bin/yq is not what they expect
  (generic problem with alternatives)

2. Giving up the Go variant in favour of fq, ship only "python"

Assuming "go" and fq overlap a lot, one might argue there's little use
in providing both. So there would by "python" as the "yq" program for
the simple use cases, everybody else please refer to fq.

Pros:
+ Packaging "python" should be simple and backportable

Cons:
- Anything specific to "go" is not available.

3. (your idea here)


Thoughts?

Christoph

¹ Fun story, years ago I implemented a little brother of "python", a
  simple Perl script that reads YAML and pipes it to jq. Not at all
  proud of it, and I'll be happy to ditch it.



signature.asc
Description: PGP signature

Bug#895405: RFP: vdo -- set of userspace tools for managing pools of deduplicated and/or compressed block storage

[Christoph Biedl]

Laurent Bigonville wrote...

> VDO (which includes kvdo and vdo) is software that provides inline
> block-level deduplication, compression, and thin provisioning
> capabilities for primary storage.

As part of an evualation of VDO, I created packages for both the kernel
and the userland. Unfortunately, the tests showed VDO, while being
functional, is not a suitable solution for the very specific
requirements here.

Therefore I will *not* take up this package, my task list is quite full
already, and not being a user of the packages one maintains is a bad
start. If however someone out there has a VDO setup in everyday usage
and wants to benefit from VDO being in Debian, drop me a line. Perhaps
we can find a way to get this done. You dont't have to be a DD, but
should have a knowledge and experience with Linux, especially in the
LVM/VDO area.

Christoph


signature.asc
Description: PGP signature

Bug#900874: ITA: schroot -- Execute commands in a chroot

[Christoph Biedl]

Control: owner 900874 !

Guilherme de Paula Xavier Segundo wrote...

> Do you want me to return the bug to your property or orphan it?

It will be better I take it back then. Luckily, somebody offered to be
co-maintainer, and we'll starting working on this the next days.

Christoph


signature.asc
Description: PGP signature

Bug#900874: O: schroot -- Execute commands in a chroot environment

[Christoph Biedl]

Christoph Biedl wrote...

> If anybody else wishes to maintain
> schroot, please go ahead before May 1st or the bullseye release,
> whatever comes first.

Well, that never happened, my bad. Somebody else asked me in private to take
this package, they have my blessings.

Christoph


signature.asc
Description: PGP signature

Bug#1003222: RFH: gkrellm-radio -- FM radio tuner for GKrellM

[Christoph Biedl]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:gkrellm-radio

[ Submitter of #440352 in Bcc: ]

Greetings,

in order to keep this package gkrellm-radio in a good shape, I've taken
over maintainership. However, I don't have such a device as an FM
receiver (yet) so I cannot test whether things work as intended.

Therefore, if someone can give this package a spin, I'd be glad. If they
are willing to do this every time I do a new upload, even better. About
the latter, I don't expect there will be more than one per year, so it
shouldn't be a big burden.

Christoph


signature.asc
Description: PGP signature

Bug#986997: ITA: netkit-telnet

[Christoph Biedl]

Simon Josefsson wrote...

> I'm considering to adopt this package, as it has been orphaned for
> around five years in Debian.  I wanted to reach out to some people
> (cc'd) that appear to have been involved in the discussions around it to
> make sure I'm not missing anything that should be considered.

My contribution is completely a thing to the past, and should be
recorded in the related bug reports: This is an entire suite of packages
which - besides being faily old - all suffered from a missing build
system so I ported it to cmake for the buster release. That was a huge
amount of work and I'm not really proud of the result. Activities
included contacting upstream, and he eventually provided a copy of the
configuration tool but I stronly doubt it's worth to revive it.

Long story short, good ride with this package. In case you want some
more old stories or additional insight, just ping me. Odds are my
reaction will be "Oh, you're right, I missed that bit".

Kind regards,

Christoph


signature.asc
Description: PGP signature

Bug#900874: O: schroot -- Execute commands in a chroot environment

[Christoph Biedl]

Control: retitle 900874 ITA: schroot -- Execute commands in a chroot

Raphaël Hertzog wrote...

> I just orphaned the schroot package. I never really want to assume its
> maintainance but it just happened that at some point I was unhappy with
> unresolved bugs with pending patches and someone had to step in and I did.
> 
> Now this package is still an important building block of our build
> infrastructure and it deserves a better maintainer than me (my last upload
> dates back to one year ago).

This package has been in limbo for way too long, and as nobody else has
stepped forward so far, I guess it's better I pick it up before worse
things happen (see #983087). But I'll have to arrange some things first,
so this will not start immediately. If anybody else wishes to maintain
schroot, please go ahead before May 1st or the bullseye release,
whatever comes first.

Putting this package under the maintainership of a yet-to-be-formed
Debian greybeard team might be an idea to think of.

Christoph


signature.asc
Description: PGP signature

Bug#981113: ITP: root -- open-source data analysis framework

[Christoph Biedl]

Julien Cristau wrote...

> On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote:
> > * Package name: root
> [...]
> > 
> > I want to maintain ROOT in the science team. ROOT was already in Debian as
> > `root-system` [1], but hasn't been updated since 2015.
> > I will probably go with a more easy maintainable route like I did with 
> > Geant4
> > for the start and do package splitting later.
> > 
> > [1] https://tracker.debian.org/pkg/root-system
> > 
> Please re-use the old name.  "root" is a terrible choice of package name.

At least. Even "root-system" is not very distict, I'd rather choose
something like "root-analysis-framework", assuming that name is a good
description for what the package does.

Christoph


signature.asc
Description: PGP signature

Bug#977536: AW: Bug#977536 closed by Debian FTP Masters (reply to Christoph Biedl ) (Bug#977536: fixed in nagios-tang 7-1)

[Christoph Biedl]

Schulz, Reiner wrote...

> Happy New Year Christoph.
> 
> Do i have to be worried about that the  architectur of the package ist 
> "armel"?

No, armel was just used for the initial upload, the Debian build daemons
will take care of the rest, current status is at[1]. So unless you intend to
use this package on kfreebsd, you'll be fine.

Christoph

[1] https://buildd.debian.org/status/package.php?p=nagios-tang
Any "Needs-Build" should disappear within the next day.


signature.asc
Description: PGP signature

Bug#977716: RFP: llhttp -- parser for HTTP messages

[Christoph Biedl]

Package: wnpp
Severity: wishlist

* Package name: llhttp
  Version : 3.0.0
  Upstream Author : Fedor Indutny 
* URL : https://github.com/nodejs/llhttp
* License : MIT
  Programming Lang: TypeScript, C
  Description : parser for HTTP messages

The http-parser library has declared unmaintained by upstream[1],
and this one here suggested as a solution to migrate to. Although
probably not a simple drop-in replacement, Debian should abandon
http-parser in favour of that one here in the long run.

However, I do not wish to do the maintainership on my own. There's a lot
of node.js involved, an area I don't feel competent do deal with.

Regards,

Christoph, maintainer of http-parser

[1] https://github.com/nodejs/http-parser/issues/522


signature.asc
Description: PGP signature

Bug#939424: O: inspircd -- Modular IRCd written in C++

[Christoph Biedl]

Control: retitle 939424 RFA: inspircd -- Modular IRCd written in C++

> The package description is:
>  InspIRCd is a modular C++ IRC Daemon for several operating systems created
>  to provide a stable, modern, lightweight irc server from scratch and provide
>  a vast number of features in a modularised form using an advanced module API.
>  By keeping the functionality of the main core to a minimum, the server is 
> very
>  stable, fast and customizable.
>  .
>  This package contains the daemon.

Well in fact, in the past two years all uploads for inspircd were done
by yours truly, and you'd also find my name in the uploaders list. Right
now, there are some bugs open that shouldn't be too difficult to handle.

So instead of letting this fall into limbo, I'll better keep it his way,
doing maintenance uploads until some caring hands will show up.

The usual stuff: Maintaining a package requires time and efforts, yada
yada ... Also, any future maintainer should have good knowledge of IRC
and inspircd as well. It's a fairly powerful IRC daemon and I have to
admit I barely touched its surface.

If you think you can handle the task of maintaining this package, get in
touch. I might be willing to sponsor the first uploads if needed.

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions

[Christoph Biedl]

Jakub Wilk wrote...

> * Christoph Biedl , 2018-11-03, 12:41:

Thanks for proof-reading. Both issues you've reported are upstream, of
course I'll bring them there.

> > It handles the * and ? jokers,
>
> s/joker/wildcard/ ?

Not sure here. Seems in English "joker" is unusual to describe a
wildcard, unlike other languages. If some native English speaker
could comment?

> > Backspace (\) is used as an escape character.
>
> I like the idea of backspace as escape character, but you probably meant
> "backslash" here. :-)

Nice idea indeed ...

Christoph


signature.asc
Description: PGP signature

Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: libregexp-wildcards-perl
  Version : 1.05
  Upstream Author : Vincent Pit 
* URL : https://metacpan.org/pod/Regexp::Wildcards
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : converts wildcard expressions to Perl regular expressions

(as created by dh-make-perl)

 In many situations, users may want to specify patterns to match but don't
 need the full power of regexps. Wildcards make one of those sets of
 simplified rules. Regexp::Wildcards converts wildcard expressions to Perl
 regular expressions, so that you can use them for matching.
 .
 It handles the * and ? jokers, as well as Unix bracketed alternatives {,},
 but also % and _ SQL wildcards. If required, it can also keep original (...)
 groups or ^ and $ anchors. Backspace (\) is used as an escape character.
 .
 Typesets that mimic the behaviour of Windows and Unix shells are also
 provided.



signature.asc
Description: PGP signature

Bug#862873: RFA: vblade-persist

[Christoph Biedl]

Daniel Kahn Gillmor wrote...

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

As you might already have seen, I've suggested a solution for
persistence at upstream. Assuming things go well - I'm fairly certain -
vblade will soon provide persistence on its own and we can RM
vblade-persist in time before the buster release.

This is mostly to inform potential adopters their work will probably be
in vain.

To ease transition for users of vblade-persist, I've already prepared a
migration script to convert configurations into the new format, it will
be part of the vblade for quite some time.

Christoph, wearing the vblade maintainer's hat


signature.asc
Description: PGP signature

Bug#894186: ITP: libtext-wagnerfischer-perl -- implementation of the Wagner-Fischer edit distance

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: libtext-wagnerfischer-perl
  Version : 0.04
  Upstream Author : Dree Mistrut <d...@friul.it>
* URL : https://metacpan.org/release/Text-WagnerFischer
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : implementation of the Wagner-Fischer edit distance

Text::WagnerFischer implements the Wagner-Fischer dynamic programming
technique, used here to calculate the edit distance of two strings. The edit
distance is a measure of the degree of proximity between two strings, based
on "edits": the operations of substitutions, deletions or insertions needed
to transform the string into the other one (and vice versa).

This package is a dependency of libdigest-ssdeep-perl (ITP is #894185)

This is to be maintained under the pkg-perl team's umbrella.

Christoph



signature.asc
Description: PGP signature

Bug#894185: ITP: libdigest-ssdeep-perl -- Pure Perl ssdeep (CTPH) fuzzy hashing

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: libdigest-ssdeep-perl
  Version : 0.9.3
  Upstream Author : Reinoso Guzman <reinoso.guz...@gmail.com>
* URL : https://metacpan.org/pod/Digest::ssdeep
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pure Perl ssdeep (CTPH) fuzzy hashing

Digest::ssdeep provides simple implementation of ssdeep fuzzy hashing also
known as Context Triggered Piecewise Hashing (CTPH).

This is to be maintained under the pkg-perl team's umbrella.

Christoph


signature.asc
Description: PGP signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

Christoph Biedl wrote...

> Adam Hupp wrote...

> > - disable the deprecation warning. this wouldn't actually show
> > anything by default unless you run python with the warning enabled
> > (-Wd), but until there's a clear plan for the future of this package
> > it seems premature to declare deprecation.
> 
> Um, I cannot see that one.

Got it, so never mind.

Christoph


signature.asc
Description: Digital signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

Adam Hupp wrote...

> Whew, I was worried for a moment :)  I've pushed an update to the
> branch

Great to see.

> Changes:
> - disable the deprecation warning. this wouldn't actually show
> anything by default unless you run python with the warning enabled
> (-Wd), but until there's a clear plan for the future of this package
> it seems premature to declare deprecation.

Um, I cannot see that one. However, there is a version bump, but in the
libmagic-compat branch only while I'd expect that one in master. Care to
check?

> - fix the libmagic test under python3.  this is actually a bug in the
> libmagic python bindings but I'd rather not make changes there.

ACK

Christoph


signature.asc
Description: Digital signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

Mathias Behrle wrote...

> I found
>
> $ apt-cache rdepends python-magic
(...)

Yeah, I already had checked a few of them where possible with little
efforts. These were the test I had been talking of (actually, including
python3-magic rdeps as well).

> May be we should signal them explicitely to test the new package in
> experimental? What do you think?

My plan is to send a call for testing to debian-devel once python-magic
has been accepted. It shouldn't hurt to add the dd-list output for these
packages. That would be 27 addresses. I might be convinced to send out
individual notices - but I think that's exaggerting. Odds for bugs are
fairly low, and there's still a lot of time until the buster freeze to
detect and fix them.

Christoph, it's called "unstable" for a reason


signature.asc
Description: Digital signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

Christoph Biedl wrote...

> Hence, here is a preliminary packaging of python-magic for Debian:
>
>   
> https://www.in-ulm.de/~cbiedl/debian/python-magic/python-magic_0.4.15-1~exp1.dsc
>
> Debianites, please give it a try.

No reaction of any kind, so just uploaded to experimental. Let the games
begin.

Christoph


signature.asc
Description: Digital signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

From the popular series "Leaving fatal mistakes in spite of
proof-reading three times":

Christoph Biedl wrote...

> Doing a first round of tests showed
   no
> regressions so far.

You may stop panicking now :)

Christoph


signature.asc
Description: Digital signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

Adam Hupp wrote...

> I've pushed an update here:
>
> https://github.com/ahupp/python-magic/tree/libmagic-compat
>
> It includes a copy of libmagic's bindings, wrapped in deprecation
> warnings.  So apps should work regardless of which they depend on.
> Could you take a look and see if this works for your case?

There are two glitches, you got mails in private about these.
Doing a first round of tests showed regressions so far.

Hence, here is a preliminary packaging of python-magic for Debian:

  
https://www.in-ulm.de/~cbiedl/debian/python-magic/python-magic_0.4.15-1~exp1.dsc

Debianites, please give it a try.

About the deprecation warning: I figured out right now (at least for
Debian) it would mostly scare users. Once Christos acknowledges your
work (hopefully) and deprecates the [file] python-magic implementation,
it's about time to alert authors of programs that use python-magic but
no earlier.

Therefore I created a switch that mutes that warning unless a
PYTHONMAGIC_WARN_DEPRECATED environment variable is set, patch below.
Using this switch, users can already test whether a particular
application needs an adjustment for the [pypi] API.

At least in Debian, I expect this transition to take two years anyway.

Cheers,

Christoph
Subject: Make the deprecation warning switchable
Author: Christoph Biedl <debian.a...@manchmal.in-ulm.de>
Date: 2018-01-08
Forwarded: soon

--- a/magic/__init__.py
+++ b/magic/__init__.py
@@ -19,6 +19,7 @@
 
 import sys
 import glob
+import os
 import os.path
 import ctypes
 import ctypes.util
@@ -325,9 +326,10 @@
 
 def deprecation_wrapper(compat, fn, alternate):
 def _(*args, **kwargs):
-warnings.warn(
-"Using compatability mode with libmagic's python binding",
-DeprecationWarning)
+if "PYTHONMAGIC_WARN_DEPRECATED" in os.environ:
+warnings.warn(
+"Using compatibility mode with libmagic's python binding",
+DeprecationWarning)
 
 return compat[fn](*args, **kwargs)
 return _


signature.asc
Description: Digital signature

Bug#877849: [tryton-debian] Namespace conflict for python-magic

[Christoph Biedl]

[
It's getting rather Debian specific, so trimming recipicient list.
I'd prefer to discuss this on debian-python but keep me in Cc:,
thanks.
]

Mathias Behrle wrote...

> while approaching the test for relatorio I got aware, that the result won't be
> very significant, because relatorio depends anyway on python-magic[pypi]. To
> get meaningful results it would be much better to get the compatibility layer
> tested with packages depending on python-magic[file-magic].
> What do you think will be the best way? I think best could be to get a 
> prepared
> package with the compatibility layer on experimental and to request the
> dependencies to give it a try.

Sorry for not getting back earlier. My plan is indeed to package [pypi]
python-magic and upload to experimental. Then testers could use that
version and look for changed behaviour.

I'll try to get something done ASAP.

Christoph



signature.asc
Description: Digital signature

Bug#854409: RFP: tang -- A server for binding data to network presence

[Christoph Biedl]

Status: Packaging is done. Drop me a line in private if you're
interested in testing (core knowledge in Debian packaging required).

Pending issues:

* jose (build dependency) is currently in NEW, must be accepted
  first.
* http-parser needs a newer version (#795492)

Christoph


signature.asc
Description: Digital signature

Bug#854410: RFP: clevis -- A plugable framework for automated decryption.

[Christoph Biedl]

Status: Packaging is done. Drop me a line in private if you're 
interested in testing (core knowledge in Debian packaging required).

Pending issues:

* jose (build dependency) is currently in NEW, must be accepted
  first.
* Same for luksmeta
* tang (build dependency) waits for jose
* License issues

Christoph



signature.asc
Description: Digital signature

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

Christoph Biedl wrote...

> Status: Packaging done but there are serious issues on other
> architectures that need fixing first.

Never mind, the test suite just takes a *long* time on slow single-core
systems. With jose just uploaded, it's now up to ftp-master.

Christoph


signature.asc
Description: Digital signature

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

retitle 873939 ITP: jose -- Jose is a C-language implementation of the 
Javascript Object Signing and Encryption standards
thanks

Christoph Biedl wrote...

> * Package name: libjose

Upstream calls it "jose", so follow this name for the source package.

>   Version : 9
>   Upstream Author : Nathaniel McCallum https://github.com/npmccallum
> * URL : https://github.com/latchset/jose
> * License : Apache-2.0
>   Programming Lang: C
>   Description : José is a C-language implementation of the Javascript 
> Object Signing and Encryption standards

Status: Packaging done but there are serious issues on other
architectures that need fixing first.

Christoph


signature.asc
Description: Digital signature

Bug#873940: ITP: libluksmeta -- LUKSMeta is a simple library for storing metadata in the LUKSv1 header

[Christoph Biedl]

Christoph Biedl wrote...

> * Package name: libluksmeta
>   Version : 7
>   Upstream Author : Nathaniel McCallum https://github.com/npmccallum
> * URL : https://github.com/latchset/luksmeta
> * License : LGPL-2.1+
>   Programming Lang: C
>   Description : LUKSMeta is a simple library for storing metadata in the 
> LUKSv1 header

Status: This package is now in NEW (as luksmeta).

Christoph


signature.asc
Description: Digital signature

Bug#877849: ITP: python-magic -- A python wrapper for libmagic

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: python-magic
  Version : 0.4.13
  Upstream Author : Adam Hupp <a...@hupp.org>
* URL : https://github.com/ahupp/python-magic/
* License : MIT
  Programming Lang: Python
  Description : A python wrapper for libmagic

Tentative long description:

python-magic is a python interface to the libmagic file type
identification library. libmagic identifies file types by checking
their headers according to a predefined list of file types.


Some background:

For quite some time, there have been two but incompatible
implementations for python-magic, providing python bindings for
libmagic (src:file).

The one provided by file ("[file]") itself might be a bit older but
appearently Adam Hupp's implementation ("[pypi]") provides a better
feature set and might even have a broader user base.

Some discussion on this took place on the debian-python list, starting
at [1]: Debian currently provides [file] so at least three packages
that require [pypi] ship their own code copy, more to come. In
upstream[2], there has been a basic understanding between Christos
Zoulas ([file]) and Adam Hupp ([pypi]) to resolve that conflict, and
Adam has announced[3] to work on a merge.

The tentative transition plan is as follows, and I'm open for
suggestions:

* Wait until [pypi] provides the [file] API.
* Ship the library using a different binary package name like
  "Package: python-magic-pypi, Provides: python-magic". Same for
  python3, here and in all the following.
* Ask users of python-magic to install this new package and check
  for regression.
* Big switch when it seems feasible: Then src:file will no longer
  provide python-magic, this package here will do insted.
  (For the records, Debian maintainer for src:file is yours truly.)
* Ask maintainers who ship a [pypi] code copy to use the package
  instead. Would be a MBF if there weren't just a few.

As my Python knowledge is limited, I'm not particulary keen on
maintaining this for Debian and I might even ITA it after the
transition. If somebody else wishes to do the job instead, please step
forward. For the filexit time however, good coordination is required.

Christoph

[1] https://lists.debian.org/debian-python/2017/09/msg8.html
[2] The file mailing list archive is down, relevant parts are
quoted in
https://lists.debian.org/debian-python/2017/09/msg00015.html
[3] https://lists.debian.org/debian-python/2017/10/msg00021.html



signature.asc
Description: Digital signature

Bug#869109: ITP: python-wifi -- Command line tool and library wrappers around iwlist and /etc/network/interfaces.

[Christoph Biedl]

Ethan Ward wrote...

> Package name: python-wifi

> This package is a dependency of mycroft-core, another python application
> that I am trying to package.

Additionally, dstat needs this for the --wifi module, and according to
codesearch, the qtile package uses it as well.

So I'm glad you've already plans for packaging, and awaiting progress.

Christoph


signature.asc
Description: Digital signature

Bug#854410: RFP: clevis -- A plugable framework for automated decryption.

[Christoph Biedl]

retitle 854410 ITP: clevis -- A plugable framework for automated decryption.
owner 854410 !
thanks

Guido Günther wrote...

> * Package name: clevis
>   Version : 2
>   Upstream Author : Nathaniel McCallum
> * URL : http://www.example.org/

That should be https://github.com/latchset/clevis

FWIW, depends also on luksmeta, ITP will follow shortly.

Christoph


signature.asc
Description: Digital signature

Bug#854409: RFP: tang -- A server for binding data to network presence

[Christoph Biedl]

retitle 854409 ITP: tang -- A server for binding data to network presence
owner 854409 !
thanks

Guido Günther wrote...

> * Package name: tang
>   Version : 4
>   Upstream Author : Nathaniel McCallum
> * URL : https://github.com/latchset/tang

> The client side is implemented in clevis. The only missing dependency in
> Debian is jose a C-language implementation of the Javascript Object
> Signing and Encryption standards.

ITP for jose will follow shortly.

Christoph


signature.asc
Description: Digital signature

Bug#873940: ITP: libluksmeta -- LUKSMeta is a simple library for storing metadata in the LUKSv1 header

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: libluksmeta
  Version : 7
  Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/luksmeta
* License : LGPL-2.1+
  Programming Lang: C
  Description : LUKSMeta is a simple library for storing metadata in the 
LUKSv1 header

LUKSmeta is a dependency for clevis which I've just ITP'd (#854410), and
probably needed by tang as well (ITP is #854409).

Christoph



signature.asc
Description: Digital signature

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: libjose
  Version : 9
  Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/jose
* License : Apache-2.0
  Programming Lang: C
  Description : José is a C-language implementation of the Javascript 
Object Signing and Encryption standards

Quoting the project homepage:

| José is a C-language implementation of the Javascript Object Signing
| and Encryption standards. Specifically, José aims towards implementing
| the following standards:
| 
| RFC 7515 - JSON Web Signature (JWS)
| RFC 7516 - JSON Web Encryption (JWE)
| RFC 7517 - JSON Web Key (JWK)
| RFC 7518 - JSON Web Algorithms (JWA)
| RFC 7519 - JSON Web Token (JWT)
| RFC 7520 - Examples of ... JOSE
| RFC 7638 - JSON Web Key (JWK) Thumbprint
| 
| José is extensively tested against the RFC test vectors.

Jose is a dependency for tang which I've just ITP'd (#854409).

Christoph


signature.asc
Description: Digital signature

Bug#860055: Inquiry about packaging progress

[Christoph Biedl]

Christoph Biedl wrote...

> * The build failure on i386 (also seen on armhf) and probably
>   all other 32bit archs needs to be fixed.

There we go:

--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 # see ENVIRONMENT in dpkg-buildflags(1)
 # package maintainers to append CFLAGS
 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
+export DEB_CFLAGS_MAINT_APPEND  = -D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

Was fairly obivous in the gpgme documenation. Build passes on all
tested architectures, amd64, i386, armhf.

Now would please somebody finish the job? :->

Christoph



signature.asc
Description: Digital signature

Bug#860055: Inquiry about packaging progress

[Christoph Biedl]

[ Dominik re-added to the loop ]

Stefan Bühler wrote...

> Yes, the .dsc files in:
>
>   https://download.opensuse.org/repositories/home:/stbuehler/Debian_9.0/
>
> work for me with dget.

Thanks. That looks pretty well, so was "violates the debian policy in
many ways" really more than just an understatement?

Besides minor cosmetical issues, there are just two things:

* libsignal-protocol-c really should be packaged separately (#840366).
  Shouldn't be a bigger issue.
* The build failure on i386 (also seen on armhf) and probably
  all other 32bit archs needs to be fixed.

(Also I haven't checked all copyright attributions. That's something for
a long rainy night.)

Cheers,
Christoph


signature.asc
Description: Digital signature

Bug#860055: Inquiry about packaging progress

[Christoph Biedl]

Stefan Bühler wrote...

> This ITP (#860055) is owned by Dominik George.

Ups, I indeed mis-directed Marcus here.

> I only wanted to give dino a short try, and preferred to have a package
> for this.  My package probably violates the debian policy in many ways,
> so it is not ready to be uploaded - I just posted a link in case it
> helps anyone else doing similar work.

While I am willing to give it a look, the opensuse developers
unfortunately spent a lot of time making web content as inaccessible as
possible. In other words, I'd need a working download link, I get either
401 or just html. Is there *anywhere* an URL I can just feed to dget?

Christoph


signature.asc
Description: Digital signature

Bug#854181: RFA: busybox --Tiny utilities for small and embedded systems

[Christoph Biedl]

tags 854181 pending
thanks

Richard Hecker wrote...

> I have used busybox over the years and would enjoy keeping it current.  I can 
> be the
> sole maintainer or work with Michael Tokarev in some teaming arrangement.  I 
> will email
> Michael directly to assess his preferences.

Your interest is appreciated, but unfortunately two Debianites already
have volunteered to take over maintaining busybox.

Christoph


signature.asc
Description: Digital signature

Bug#862644: O: libproc-syncexec-perl -- spawn processes but report exec() errors properly

[Christoph Biedl]

retitle 862644 ITA: libproc-syncexec-perl -- spawn processes but report exec() 
errors properly
thanks

> The current maintainer of libproc-syncexec-perl, Roderick Schertler 
> ,
> is apparently not active anymore.  Therefore, I orphan this package now.

In spite of a pretty low popcon rank my gut feeling tells me this
package should stay in Debian. So I intent to put it under the pkg-perl
team's umbrella.

Christoph


signature.asc
Description: Digital signature

Bug#868447: O: sendxmpp -- commandline XMPP (jabber) utility

[Christoph Biedl]

Guus Sliepen wrote...

> If noone steps up, I will file a RM request in the current release
> cycle.

Ping me before you do that.

Read: While I'm a somewhat active user of this program and also the underlying
libnet-xmpp-perl, given my real-life constraints I should be carefull about
increasing my commitment for Debian. But before we loose this package ..

If anybody else wishes to take over, go ahead.

Christoph


signature.asc
Description: Digital signature

Bug#761817: RFP: arangodb -- ArangoDB is a multi-model mostly-memory database with a flexible data model for documents and graphs.

[Christoph Biedl]

Kjetil Kjernsmo wrote...

> ArangoDB is a multi-purpose open-source database with a flexible data
> model for documents, graphs and key-values. You can easily build high
> performance applications using a convenient SQL-like query language or
> JavaScript extensions.
(...)
> The project provides Debian packages already, so packaging it has
> already a start.

As somebody else asked me to bring arangodb into Debian, I did some
research and wish to share the result:

While upstream does provide Debian packages, the packaging itself is not
included: There are no sources in the repository[1], and the sources at
github do not include a debian/ directory.

Furthermore, the sources include several code copies that have to be
replaced with the according packages in Debian, or need separate
packaging first. In detail, as found in arangodb 3.1.7:

,-Version as included in the ArangoDB sources
|   ,- Debian stretch
|   |   ,- Debian jessie

boost   1.62.0  1.62.0+dfsg-4   1.55.0+dfsg-3(!)
curl7.50.3  7.52.1-47.38.0-4
linenoise-ng?   -   -
rocksdb 4.8.0   4.5.1-2 -
snappy  1.1.3   1.1.3-3 1.1.2-3(!)
v8  5.0.71.39   3.14.5.8-11(!)  3.14.5.8-8.1(!)
valgrind?   1:3.12.0~svn20160714-1+b1
1:3.10.0-4
velocypack  ?   -   -
zlib1.2.8   1:1.2.8.dfsg-5  1:1.2.8.dfsg-2+b1


Now, linenoise-ng and velocypack have to be packaged first, I did not
even see an RFP/ITP yet. They should be easly tasks though in both
packaging and license. The big issue however is v8 which is horribly
outdated in Debian for reasons I don't know. And even if that old
version should work, it has no security support[2].

Therefore, packaging arangodb for Debian requires some work and might
still be impossible to achieve. As always, maintaining a Debian package
should be done by someone who uses that software constantly. That would
not be me.

Christoph

[1] https://www.arangodb.com/repositories/arangodb31/Debian_8.0/
[2] 
https://sources.debian.net/src/libv8-3.14/3.14.5.8-11/debian/README.Debian.security/


signature.asc
Description: Digital signature

Bug#849842: ITP: ykush-control -- control application for Yepkit YKUSH Switchable USB Hub board

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: ykush-control
  Version : 1.0.0
  Upstream Author : 2015-2016 Yepkit Lda
* URL : https://github.com/Yepkit/ykush
* License : MIT
  Programming Lang: C++
  Description : control application for Yepkit YKUSH Switchable USB Hub 
board

 The Yepkit USB Switchable Hub (YKUSH) boards allow the user to
 selectively switch ON and OFF each of the USB devices connected to the
 hub downstream ports. This package provides the ykushcmd program to
 control the switches of all connected boards.



signature.asc
Description: Digital signature

Bug#849332: ITP: auto-resize-image -- Resizer for inline and attachment images (thunderbird)

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: auto-resize-image
  Version : 0.14.3-tb
  Upstream Author : TrVTrV 
<https://addons.mozilla.org/en-US/thunderbird/user/trvtrv/>
* URL : 
https://addons.mozilla.org/en-US/thunderbird/addon/auto-resize-image/
* License : GPL2+
  Programming Lang: XUL
  Description : Resizer for inline and attachment images (thunderbird)


Tentative long description:

 Auto Resize Image is a Thunderbird add-on which allows one to resize
 inline and attached images while composing email messages.
 .
 The main purpose is to:
  - reduce size of image files
  - give the image convenient dimensions for it to be visible directly
in email client without using scrollbars.

Personally, I'm a bit surprised this very useful tool does not exist in
Debian yet - or did I just not see it?

Additionally, my main interest is to have this plugin in Debian - while
I'm not particularily keen on maintaining it. So if anybody else wishes
to do this, perhaps under the pkg-mozext umbrella, just let me know.

Christoph



signature.asc
Description: Digital signature

Bug#655265: ITA isdnactivecards isdnutils

[Christoph Biedl]

retitle 655265 ITA: isdnactivecards -- ISDN utilities - active ISDN card support
owner 655265 !
retitle 661110 ITA: isdnutils -- ISDN utilities
owner 661110 !
thanks

As probably one of the last users of ISDN hardware I'd like to adopt
these packages. I am aware ISDN is a thing of the past now, let it live
its final days in dignity.

For stretch, I'd plan at least one cleanup upload for both packages. If
you see something that certainly should be fixed and I might overlook,
drop me a line. As usual, tested patches increase the chance for a bug
getting handled.

Christoph


signature.asc
Description: Digital signature

Bug#848547: RFA: u3-tool -- tool for controlling the special features of a U3 USB flash disk

[Christoph Biedl]

retitle 848547 ITA: u3-tool -- tool for controlling the special features of a 
U3 USB flash disk
owner 848547 !
thanks

Evgeni Golov wrote...

> I request an adoption of u3-tool, as I do not have any U3 capable devices
> and no need for the tool anymore.

Well, I happen to have a few. And although the u3 technology is a bit
outdated now, there still are people using it. Also there is a
long-standing bug I'd like to fix.

Cheers,

Christoph


signature.asc
Description: Digital signature

Bug#848990: O: tuxpaint-stamps -- Stamp files for Tux Paint, a paint program for children

[Christoph Biedl]

Package: wnpp
Severity: normal

Ben Armstrong, maintainer of the tuxpaint-stamps package, has retired
from the Debian project. Therefore I orphan this package.


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/index.html#howto-o for detailed
instructions how to adopt a package properly.


Some information about this package:

Popcon rank (as of today): 1686

Source: tuxpaint-stamps
Section: graphics
Priority: optional
Build-Depends: debhelper (>> 5)
Maintainer: Ben Armstrong 
Standards-Version: 3.9.6

Package: tuxpaint-stamps-default
Architecture: all
Provides: tuxpaint-stamps
Depends: ${misc:Depends}
Recommends: tuxpaint
Description: Stamp files for Tux Paint, a paint program for children
 Tux Paint is meant to be a simple drawing program for young
 children.  It is not meant as a general-purpose drawing tool.
 It IS meant to be fun and easy to use.  Sound effects and a
 cartoon character help let the user know what's going on, and
 keeps them entertained.
 .
 Tux Paint is extensible.  Brushes and "rubber stamp" shapes can be
 dropped in and pulled out.  For example, a teacher can drop in a
 collection of animal shapes and ask their students to draw an
 ecosystem.  Each shape can have a sound which is played, and
 textual facts which are displayed, when the child selects the shape.
 .
 There is no direct access to the computer's underlying intricacies.
 The current image is kept when the program quits, and reappears when
 it is restarted.  Saving images requires no need to create filenames
 or use the keyboard.  Opening an image is done by selecting it from
 a collection of thumbnails.
 .
 This package contains sounds, images and other data for Tux Paint.


signature.asc
Description: Digital signature

Bug#848988: O: tuxpaint -- Paint program for young children

[Christoph Biedl]

Package: wnpp
Severity: normal

Ben Armstrong, maintainer of the tuxpaint package, has retired
from the Debian project. Therefore I orphan this package.


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/index.html#howto-o for detailed
instructions how to adopt a package properly.


Some information about this package:

Maximum popcon rank (as of today): 1690 tuxpaint-plugins-default

Source: tuxpaint
Section: graphics
Priority: optional
Maintainer: Ben Armstrong 
Build-Depends: debhelper (>= 5.0.51~), gettext, libfribidi-dev, libsdl1.2-dev, 
libsdl-image1.2-dev, libsdl-mixer1.2-dev (>= 1.2.4-1.1), libsdl-ttf2.0-dev, 
libsdl-pango-dev, libpng-dev, libvorbis-dev (>= 1.0.0-2), librsvg2-dev, 
libcairo2-dev, libpaper-dev, gperf
Standards-Version: 3.9.6

Package: tuxpaint
Architecture: any
Depends: tuxpaint-plugins-default (>= 1:0.9.22-1) | tuxpaint-plugins, 
tuxpaint-data (= ${source:Version}), ${shlibs:Depends}, libvorbis0a (>= 
1.0.0-2), libvorbisfile3 (>= 1.0.0-2), netpbm, ${misc:Depends}
Recommends: tuxpaint-config
Description: Paint program for young children
 Tux Paint is meant to be a simple drawing program for young
 children.  It is not meant as a general-purpose drawing tool.
 It IS meant to be fun and easy to use.  Sound effects and a
 cartoon character help let the user know what's going on, and
 keeps them entertained.
 .
 Tux Paint is extensible.  Brushes and "rubber stamp" shapes can be
 dropped in and pulled out.  For example, a teacher can drop in a
 collection of animal shapes and ask their students to draw an
 ecosystem.  Each shape can have a sound which is played, and
 textual facts which are displayed, when the child selects the shape.
 .
 There is no direct access to the computer's underlying intricacies.
 The current image is kept when the program quits, and reappears when
 it is restarted.  Saving images requires no need to create filenames
 or use the keyboard.  Opening an image is done by selecting it from
 a collection of thumbnails.

Package: tuxpaint-plugins-default
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: tuxpaint-plugins
Description: Magic tool plugins for Tux Paint
 Tux Paint is meant to be a simple drawing program for young
 children.  It is not meant as a general-purpose drawing tool.
 It IS meant to be fun and easy to use.  Sound effects and a
 cartoon character help let the user know what's going on, and
 keeps them entertained.
 .
 Tux Paint is extensible.  Brushes and "rubber stamp" shapes can be
 dropped in and pulled out.  For example, a teacher can drop in a
 collection of animal shapes and ask their students to draw an
 ecosystem.  Each shape can have a sound which is played, and
 textual facts which are displayed, when the child selects the shape.
 .
 There is no direct access to the computer's underlying intricacies.
 The current image is kept when the program quits, and reappears when
 it is restarted.  Saving images requires no need to create filenames
 or use the keyboard.  Opening an image is done by selecting it from
 a collection of thumbnails.
 .
 This package contains the default "Magic" plugins for Tux Paint.

Package: tuxpaint-dev
Architecture: all
Depends: ${misc:Depends}
Description: Development files for Tux Paint
 This package contains development files for writing "Magic" plugins
 for Tux Paint.

Package: tuxpaint-data
Architecture: all
Depends: tuxpaint-stamps-default | tuxpaint-stamps, fonts-freefont-ttf, 
${misc:Depends}
Recommends: tuxpaint
Suggests: fonts-arabeyes, fonts-arphic-gbsn00lp, fonts-arphic-uming, 
fonts-nanum, fonts-gujr, fonts-taml, fonts-telu, fonts-thai-tlwg
Description: Data files for Tux Paint, a paint program for children
 Tux Paint is meant to be a simple drawing program for young
 children.  It is not meant as a general-purpose drawing tool.
 It IS meant to be fun and easy to use.  Sound effects and a
 cartoon character help let the user know what's going on, and
 keeps them entertained.
 .
 Tux Paint is extensible.  Brushes and "rubber stamp" shapes can be
 dropped in and pulled out.  For example, a teacher can drop in a
 collection of animal shapes and ask their students to draw an
 ecosystem.  Each shape can have a sound which is played, and
 textual facts which are displayed, when the child selects the shape.
 .
 There is no direct access to the computer's underlying intricacies.
 The current image is kept when the program quits, and reappears when
 it is restarted.  Saving images requires no need to create filenames
 or use the keyboard.  Opening an image is done by selecting it from
 a collection of thumbnails.
 .
 This package contains sounds, images, fonts and other data for
 Tux Paint.


signature.asc
Description: Digital signature

Bug#848989: O: tuxpaint-config -- Paint program for young children

[Christoph Biedl]

Package: wnpp
Severity: normal

Ben Armstrong, maintainer of the tuxpaint-config package, has retired
from the Debian project. Therefore I orphan this package.


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/index.html#howto-o for detailed
instructions how to adopt a package properly.


Some information about this package:

Popcon rank (as of today): 1582

Source: tuxpaint-config
Section: graphics
Priority: optional
Maintainer: Ben Armstrong 
Build-Depends: debhelper (>= 5.0.0), libfltk1.3-dev, libxft-dev, 
libxinerama-dev, libpaper-dev
Standards-Version: 3.9.6

Package: tuxpaint-config
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: tuxpaint (= 1:0.9.22)
Conflicts: tuxpaint (<< 1:0.9.22)
Description: Configuration tool for Tux Paint
 Tux Paint has a rich set of configuration options, controllable via
 command-line options or configuration files.  This configuration tool
 provides a point-and-click interface for administrators to tailor Tux
 Paint to suit the needs of their users.


signature.asc
Description: Digital signature

Bug#848987: O: junior-doc -- Debian Jr. Documentation

[Christoph Biedl]

Package: wnpp
Severity: normal

Ben Armstrong, maintainer of the junior-doc package, has retired
from the Debian project. Therefore I orphan this package.


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/index.html#howto-o for detailed
instructions how to adopt a package properly.


Some information about this package:

Source: junior-doc
Section: doc
Priority: extra
Maintainer: Ben Armstrong 
Standards-Version: 3.5.9
Build-Depends-Indep: debiandoc-sgml, texlive-latex-recommended, 
texlive-latex-extra, texlive-fonts-recommended

Package: junior-doc
Architecture: all
Suggests: www-browser, postscript-viewer
Description: Debian Jr. Documentation
 Includes, for the moment, just the "Quick Guide" which helps a new user
 of Debian Jr. get started.  The intention of the Debian Jr. working
 group is to provide a variety of additional documents to help children
 and sys admins alike with the installation, configuration, and use of a
 Debian Jr. system.


signature.asc
Description: Digital signature

Bug#848922: O: xpilot-extra

[Christoph Biedl]

Package: wnpp
Severity: normal

Ben Armstrong, maintainer of the xpilot-extra package, has retired
from the Debian project. Therefore I orphan this package (mostly
to do a QA upload immediatly afterwards :)

The following text was stolen from the QA/MIA folks:

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/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Source: xpilot-extra
Section: games
Priority: optional

Package: xpilot-extra
Architecture: all
Depends: perl
Suggests: xpilot-ng
Conflicts: xpilot (<< 4.1.0-4.U.4alpha2.1)
Description: Maps, utilities and configs for XPilot
 XPilot is a multi-player tactical manoeuvring game for X.  Each
 player controls their own fighter equipped with a variety of weapons
 and power-ups.  Players compete as teams or as individuals;  the
 object of the game is to score points by blasting the opposition,
 stealing their treasure or by racing round a circuit.
 WARNING: This game is very addictive.
 .
 This package contains all the maps available from ftp.xpilot.org
 (plus a few others), a useful command line utility for interrogating
 the metaserver and a few configuration files submitted by players to
 help get you started.



signature.asc
Description: Digital signature

Bug#843435: O: aoetools -- tools to assist in using ATA over Ethernet

[Christoph Biedl]

retitle 843435 ITA: aoetools -- tools to assist in using ATA over Ethernet
retitle 845285 ITA: vblade -- virtual AoE blade emulator
thanks

For the reasons explained recently in #843435 I hereby declare my
intent to maintain both aoetools and vblade.

The vblade package has seen a new upstream release. If anybody wants
that in stretch although the changes were rather small, please wait
until Dec 20th when I'm hopefully past the FD/DAM phase, or sponsor
the upload for me.

Cheers,

Christoph



signature.asc
Description: Digital signature

Bug#835865: RFP: blocks -- deep learning framework build on the top of Theano

[Christoph Biedl]

Daniel Stender wrote...

> * Package name: blocks
>   Version : 0.2.0
>   Upstream Author : Université de Montréal, LISA lab/MILA 
> 
> * URL : https://github.com/mila-udem/blocks
> * License : Expat
>   Programming Lang: Python
>   Description : deep learning framework build on the top of Theano

Better late than never: There is a completely different project called
"blocks" as well, conversion tools for block devices[1], I might file
an ITP for this. So I'm asking you to consider a different and more
distinctive name, perhaps "theano-blocks". I would choose something
like blocks-conversion or blocks-tools then.

Cheers,
Christoph

[1] https://github.com/g2p/blocks


signature.asc
Description: Digital signature

Bug#843435: O: aoetools -- tools to assist in using ATA over Ethernet

[Christoph Biedl]

Tobias Frost wrote...

> The current maintainer of aoetools, David Martínez Moreno ,
> is apparently not active anymore.  Therefore, I orphan this package now.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

As a regular user of AoE, I'm interested in having a well-maintained
aoetools package in Debian. However, for reasons mostly outside my
control I shall not pick up more packages until a certain point in the
future which is somewhere between two weeks and six months from now.
ITA will follow then.

So, if anybody else wishes to take over, just go ahead.

If however this package needs urgent attention, most likely about
inclusion in stretch: Contact me, I'll be there.

Christoph


signature.asc
Description: Digital signature

Bug#829833: ITP: libdate-holidays-de-perl -- Determine German holidays

[Christoph Biedl]

Christoph Biedl wrote...

> * Package name: libdate-holidays-de-perl
>   Version : 1.7
>   Upstream Author : Martin Schmitt 
> * URL : http://search.cpan.org/dist/Date-Holidays-DE/

Preliminary packaging available at
http://www.in-ulm.de/~cbiedl/debian/libdate-holidays-de-perl/libdate-holidays-de-perl_1.7-1.dsc

Christoph


signature.asc
Description: Digital signature

Bug#733453: RFP: libbgpdump -- C library designed to help with analyzing dump files produced by Zebra/Quagga or MRT

[Christoph Biedl]

retitle 733453 ITP: bgpdump -- C library designed to help with analyzing dump 
files produced by Zebra/Quagga or MRT
owner 733453 !
thanks

Some time has passed but I'm still interested in doing this. Since
upstream's name for that package is "bgpdump", I've changed the
package name accordingly.

Find a preliminary packaging at

http://www.in-ulm.de/~cbiedl/bgpdump/bgpdump_1.4.99.15+hg127-1~pre1.dsc
sha256sum: cb980002e2ad81cdbd489a17306a5626a167b4d828bccdc8f8a19c814dc468c4

Open tasks:

- Upstream patches that should go there (quite a few).
- Write a watch file.

And by the way, as my NM process makes rather slow progress, final
upload will take a few weeks. If you want to sponsor that packaging,
drop me a line.

Christoph


signature.asc
Description: Digital signature

Bug#829833: ITP: libdate-holidays-de-perl -- Determine German holidays

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl <debian.a...@manchmal.in-ulm.de>

* Package name: libdate-holidays-de-perl
  Version : 1.7
  Upstream Author : Martin Schmitt 
* URL : http://search.cpan.org/dist/Date-Holidays-DE/
* License : ISC
  Programming Lang: Perl
  Description : Determine German holidays

This module provides a function to get a list of German holidays for a
given year. It also knows about different regulations throughout
Germany.

This package should by maintained by the pkg-perl team. I will also
need a sponsor but I doubt this will be a problem.

Christoph



signature.asc
Description: Digital signature

Bug#779841: ITP: libmonitoring-plugin-perl -- family of perl modules to streamline writing Monitoring plugins

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> I have something ready, I only miss the replacing part for
> libnagios-plugin-perl via a transitional package.

When looking at the package some two months ago, I got the impression
providing a transition layer for users of libnagios-plugin-perl (i.e.
injecting according function and variable names into Perl's namespace)
means a lot of painful work and still has some pitfalls. So in my
opinion: While of course it was nice to ease these peoples' life, it's
not worth to spend too much effort on that, and I'd rather advise them
to change their code, it's the saner thing to do anyway.

Did this for my nagi^W monitoring checks using a preliminary packaging
of Monitoring::Plugins. And I'm glad to hear this transitional
situation will come to an end.

Christoph


signature.asc
Description: Digital signature

Bug#733453: RFP: libbgpdump -- C library designed to help with analyzing dump files produced by Zebra/Quagga or MRT

[Christoph Biedl]

Christoph Biedl wrote...

 * Package name: libbgpdump
 
 Throwing my hat in the ring ...

Just a short status update: Packaging is done and ready for upload.
However, during testing I found several serious issues in the code
besides the ones that are already public. So I am now waiting for a
sign of life from upstream to have them fixed there, not just in the
Debian package.

Upload will probably not happen before June 5th, stay tuned.

Christoph


signature.asc
Description: Digital signature

Bug#733453: RFP: libbgpdump -- C library designed to help with analyzing dump files produced by Zebra/Quagga or MRT

[Christoph Biedl]

retitle 733453 ITP: libbgpdump -- C library designed to help with analyzing 
dump files produced by Zebra/Quagga or MRT
owner 733453 !
thanks

Bob Bib wrote...

 * Package name: libbgpdump

Throwing my hat in the ring ...

Unless someone objects, I'll ship the bgpdump binary only. The
libbgpdump.so is built without soname and not even used by the binary
itself since that one is linked statically.

Cheers,

Christoph


signature.asc
Description: Digital signature

Bug#661341: ITP: anope -- a set of IRC Services designed for flexibility and ease of use

['Christoph Biedl']

Dominic Hargreaves wrote...

 I'm now looking at the packaging of Anope 1.8.8 so in the absence
 of further responses from Christopher am taking ownership of this
 bug. Of course, if Christopher would like to get involved again I'd
 be very happy to collaborate.

Ups. Seems I either oversaw your previous message or I forgot about
it. Since, however, I did not continue my work on Anope anyway, that
package is probably better in your hands.

One request ...  please do the ngircd users a favour and
package 1.9.x since 1.8.x does not have support for ngircd yet.

From my remembrance, Debianisation of Anope wasn't easy, mostly since
it appearently wasn't written with Debian's requirements in mind (just
saying, no one to blame here). I can provide you my incomplete
Debianisation of 1.9.6, but with a no questions asked policy only :)
It's just I forgot most of the gory details. The major things and as
far as I can recall:

* Anope's file system layout is not at all FHS-like, you have to patch
  that. Expect some surprises.

* The module loader uses randomized file names. Completely
  unnecessary, drop that.

* There is an openssl linkage without an according exception by
  upstream. Try to get one (I failed), or ship Anope without.

Cheers,

Christoph


signature.asc
Description: Digital signature

Bug#465227: ITP: libdevice-gsm-perl -- Perl extension to interface GSM phones / modems

[Christoph Biedl]

retitle 465227 ITP: libdevice-gsm-perl -- Perl extension to interface GSM 
phones / modems
owner 465227 !
thanks

 Package: wnpp
 Severity: wishlist
 
 Package used to communicate with GSM devices from perl, can be used
 to send textmessages etc.
 For more information please see http://search.cpan.org/dist/Device-Gsm/

Throwing my hat in the ring ...

Cheers,

Christoph


signature.asc
Description: Digital signature

Bug#661341: ITP: anope -- a set of IRC Services designed for flexibility and ease of use

[Christoph Biedl]

Christoph Biedl wrote...

 * Package name: anope
   Version : 1.9.6
   Upstream Author : Anope Team t...@anope.org

The Anope project leader has asked me not to upload my packaging, not
even to experimental, until anope has evolved into somewhat more
stable. That might take one or two years.

Since I'm not at all interested in working against upstream's
intention, I will follow that request, sadly though.

Christoph



signature.asc
Description: Digital signature

Bug#661341: ITP: anope -- a set of IRC Services designed for flexibility and ease of use

[Christoph Biedl]

Package: wnpp
Owner: Christoph Biedl debian.a...@manchmal.in-ulm.de
Severity: wishlist

* Package name: anope
  Version : 1.9.6
  Upstream Author : Anope Team t...@anope.org
* URL : http://www.anope.org/index.php
* License : GPL-2.0
  Programming Lang: C++
  Description : a set of IRC Services designed for flexibility and ease of 
use

=
Anope is a set of Services for IRC networks that allows users to
manage their nicks and channels in a secure and efficient way, and
administrators to manage their network with powerful tools.

Currently available services are: NickServ, ChanServ, MemoServ,
BotServ, OperServ, and HostServ.

Anope currently works with:
  - Bahamut 1.4.27 or later (including 1.8)
  - InspIRCd 1.1, 1.2, or 2.0
  - Ratbox 2.0.6 or later
  - UnrealIRCd 3.2 or later
  - Plexus 3 or later
  - ngIRCd 19 or later
=

A remark:

Support for ngIRCd is not part of the Anope upstream yet, the patches
have been taken from the upcoming ngircd release 19.

Christoph


signature.asc
Description: Digital signature

Bug#575502: ITP: certificatepatrol

[Christoph Biedl]

retitle 575502 ITP: certificatepatrol - Certificate Watcher for 
Iceweasel/Icedove etc.
owner 575502 !
exit

Christoph Anton Mitterer wrote...

 * Package name: certificatepatrol

There should be few doubt interest in this package rose a bit
recently, at least for me. So I'll do the packaging, stay tuned.

A question:

 * License : MPL 1.1, GPL 2.0, LGPL 2.1

In the related documents I found MPL 1.1 only. Do you have other
information about the licensing - upstream might have changed that,
too.

Christoph


signature.asc
Description: Digital signature

Bug#509864: RFP: foswiki -- The Free and Open Source Wiki

[Christoph Biedl]

Sven Dowideit wrote a long time ago ...

 Additionally, the foswiki deb package and 106 od the Foswiki Extensions
 built into deb's are available from my debian repository at
 
 http://fosiki.com/Foswiki_debian

Mind me asking for progress?  I'd really like to see foswiki uploaded
to Debian, and I bet this would increase the number of testers.

Christoph



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#401113: ITP: nagiosgrapher -- A graphing system for the Nagios monitoring system project.

[Christoph Biedl]

retitle 401113 RFP: nagiosgrapher -- A graphing system for the Nagios 
monitoring system project.
thankyou

Hi,

several months ago I wrote:

 Package: wnpp
 Owner: Christoph Biedl [EMAIL PROTECTED]
 
 * Package name: nagiosgrapher

Unfortunatly I never managed to create a full package and I use
different tools for visualisation now.  Therefore I'd better retreat
this ITP and I'll leave it as an RFP in case anybody else wishes to take
over.

Christoph


signature.asc
Description: Digital signature

Bug#401113: ITP: nagiosgrapher -- A graphing system for the Nagios monitoring system project.

[Christoph Biedl]

Package: wnpp
Owner: Christoph Biedl [EMAIL PROTECTED]
Severity: wishlist

* Package name: nagiosgrapher
  Version : 1.5-dev
  Upstream Author : Gerd Mueller gmueller __at__ netways __dot__ de
* URL : http://www.nagiosexchange.org/NagiosGrapher.84.0.html
http://freshmeat.net/projects/nagiosgrapher/
* License : GPL
  Description : A graphing system for the Nagios monitoring system project.

Quoting the second URL above:
The NagiosGrapher is a graphing system for the Nagios monitoring system
project. Every numeric datum Nagios collects can be graphed with this
project. It uses template definitions to connect the data sources with
the graph, so it's possible to graph a huge amount of services with a
minimum of definitions. Every new service which fits the template will
be graphed. To forward the values to the graphing engine there is no
special interface needed. NagiosGrapher uses the built-in functions from
Nagios.

An additional remark, this package should not be confused with
nagiosgraph which has a similar goal but is much less powerful.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.18.2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)



signature.asc
Description: Digital signature