Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

2022-08-13 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: netbox
  Version : 3.2.8
  Upstream Author : Jeremy Stretch 
* URL : https://github.com/netbox-community/netbox
* License : Apache-2.0 and MIT/X
  Programming Lang: Python
  Description : WebUI based tool designed to manage and document computer 
networks

 NetBox is a Django based web application, initially conceived by the network
 engineering team at DigitalOcean, NetBox was developed specifically to address
 the needs of network and infrastructure engineers. It encompasses the following
 aspects of network management:
 .
  * Hierarchical regions, site groups, sites, and locations
  * Racks, devices, and device components
  * Cables and wireless connections
  * Power distribution
  * Data circuits and providers
  * Virtual machines and clusters
  * IP prefixes, ranges, and addresses
  * VRFs and route targets
  * FHRP groups (VRRP, HSRP, etc.)
  * AS numbers
  * VLANs and scoped VLAN groups
  * Organizational tenants and contacts
 .
 In addition to its extensive built-in models and functionality, NetBox can
 be customized and extended through the use of:
 .
  * Custom fields
  * Custom links
  * Configuration contexts
  * Custom model validation rules
  * Reports
  * Custom scripts
  * Export templates
  * Conditional webhooks
  * Plugins
  * Single sign-on (SSO) authentication
  * NAPALM integration
  * Detailed change logging
 .
 NetBox also features a complete REST API as well as a GraphQL API for easily
 integrating with other tools and systems.
 .
 While NetBox strives to cover many areas of network management, the scope of
 its feature set is necessarily limited. This ensures that development focuses
 on core functionality and that scope creep is reasonably contained. To that
 end, it might help to provide some examples of functionality that NetBox does
 not provide:
 .
  * Network monitoring
  * DNS server
  * RADIUS server
  * Configuration management
  * Facilities management


I plan to maintain netbox within the Debian Python Team ideally together
with some more interested people in managing the maintenance.
Right now all needed build and binary package dependencies are
fulfilled, as NetBox is getting actively developed it constantly
bugfixes and new added features which might need new dependencies in the
near future which are not packed yet. I'd like to see (if possible) the
netbox package within the bookworm release.

The NetBox UI is using some comprehensive JS files which are shipped as
minimized files. Currently I'm unable to drop the shipped minimized code
and rebuild all the needed files from scratch. If possible I'd like to
get some help on this, currently netbox will need to go into non-free due
the non rebuild-able minimized files.
OTOH netbox can't go into main as it requires at least one package from
non-free, it requires drf-yasg-nonfree for some Swagger functionality.

Regards
Carsten



Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

2022-08-15 Thread Carsten Schoenert

Hello Lucas,

Am 15.08.22 um 17:24 schrieb Lucas Castro:

Carsten,

It seems like a good project,

Tell me if you need on this.


thanks, and thanks also for taking interest!
I've forgotten t point to the current data and packages while writing 
the ITP.


I'm working on packaging NetBox for almost a year now and run successful 
some small test installations locally and on my day job.


I've uploaded locally created packages to p.d.o regularly.

https://people.debian.org/~tijuca/netbox/

I'm using a Git tree within my namespace to hold up my work while 
working on netbox packaging, I'm taking the freedom to do force pushing 
to that tree as long the initial packaging work isn't uploaded into NEW.


https://salsa.debian.org/tijuca/netbox

The installed package is working if you going through README.Debian and 
proceed some steps manually.
I'd like to minimize manual steps much as possible, but without 
bothering admins that using a central configuration management.
If you want to try out the already existing package and internal 
packaging I'm sure you will find some points that are worth to get 
improved before a initial upload.


I've also have some more ideas what to do, some of them I've written to 
wiki.d.o. If you want to extend please do so. Now the ITP is written a 
dedicated Wiki page about NetBox might a good thing to do.


https://wiki.debian.org/CarstenSchoenert#NetBox

--
Regards
Carsten



Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

2022-08-15 Thread Carsten Schoenert

Hello Vincent,

Am 15.08.22 um 19:46 schrieb Vincent Bernat:

It also looks like drf-yasg-nonfree is non-free just because of the
minimized JS files. This is often a problem and while not everybody
agrees with this, you can workaround this issue by shipping the
non-minified sources in debian/missing-sources.


your analysis about the reason is correct.
The specific problem with drf-yasg is that even upstream could not fully 
explain how to rebuild or even collect the source files for the 
minimized files. This means not that this is solvable, but for me it's 
mostly the time factor (but also my nearly zero knowledge about the 
node.js universe) to entangle this all. This area is heavily moving 
target, unfortunately. It might happen that NetBox is dropping drf-yasg 
in favor of some other library.



You may or may not use them in the build process. Maybe it does not
hurt to try to run a minifier (like uglifyjs) on them if you feel
like it. As long as upstream is using the files as is, the FTP
masters are likely to accept a package with the sources in
debian/missing.
I wanted to do exactly this, but this requires a good knowledge what's 
going on under the hood. And currently I don't know enough how to get 
all these peaces together and if someone with more "how to analyze and 
rebuild the minimized JS" knowledge is willing to jump in would be 
really appreciated.


If some things are more sorted out I wanted to run the yarn calling 
script from the NetBox sources to get some logging about the downloading 
of the source files and the kind of all the parts are glued together.


There are some parts of the source for some minimized files are shipped 
by the NetBox project. But that's not all.


https://github.com/netbox-community/netbox/tree/develop/netbox/project-static/src

Thanks for your interest and feedback!

--
Regards
Carsten



Bug#1020611: ITP: python-trio-websocket -- Server and client Python library of the WebSocket protocol

2022-09-24 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-trio-websocket
  Version : 0.9.2
  Upstream Author : John Belmonte 
* URL : https://github.com/HyperionGray/trio-websocket
* License : MIT/X
  Programming Lang: Python
  Description : Server and client Python library of the WebSocket protocol

 This library implements both server and client aspects of the WebSocket
 protocol, striving for safety, correctness, and ergonomics. It is based on the
 wsproto project, which is a Sans-IO state machine that implements the majority
 of the WebSocket protocol, including framing, codecs, and events. This library
 handles I/O using the Trio framework. This library passes the Autobahn Test
 Suite.

This package is a new dependency for python-selenium and will be
maintained within the Debian Python team.



Bug#1022155: ITP: mkdocs-click -- MkDocs extension to generate documentation for Click command line applications

2022-10-20 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocs-click
  Version : 0.8.0
  Upstream Author : packa...@datadoghq.com
* URL : https://github.com/DataDog/mkdocs-click
* License : Apache-2.0
  Programming Lang: Python
  Description : MkDocs extension to generate documentation for Click 
command line applications

 This package contains a MkDocs extension that lets you generate the
 documentation for the Click command line applications within your documentation
 dynamic created from the source code files.

This package is new build dependency for python-mkdocs >= 1.4.1.

It will be maintained within the Debian Python Team.



Bug#1022207: ITP: pysocks -- Lets you send traffic through SOCKS proxy servers

2022-10-21 Thread Carsten Schoenert

Hi,

Am 22.10.22 um 01:44 schrieb Josenilson Ferreira da Silva:

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

  It is a modern fork of SocksiPy with bug fixes and extra
  features. Acts as a drop-in replacement to the socket module.
  Seamlessly configure SOCKS proxies for any socket object by
  calling socket_object.set_proxy().
  .
  Features:
   - SOCKS proxy client for Python 2.7 and 3.4+
   - TCP supported, UDP mostly supported (issues may occur in
 some edge cases).
   - HTTP proxy client included but not supported or recommended
 (you should use requests', or your HTTP client's, own HTTP
 proxy interface).
* Package name: pysocks
   Version : 1.7.0
   Upstream Author :  Anorov 
* URL : https://github.com/Anorov/PySocks
* License : BSD-3-clause
   Programming Lang: Python
   Description : Lets you send traffic through SOCKS proxy servers

  Note:
  package is a required dependency for packaging from
  https://github.com/sherlock-project/sherlock


a quick check on the CLI shows me that this seems to be already packaged.
Did you have checked this before writing the ITP?


$ apt show python3-socks
Package: python3-socks
Version: 1.7.1+dfsg-1
Priority: optional
Section: python
Source: python-socksipy
Maintainer: Debian Python Team 
Installed-Size: 78,8 kB
Depends: python3:any
Breaks: python3-pysocks, python3-socksipy
Replaces: python3-pysocks, python3-socksipy
Homepage: https://github.com/Anorov/PySocks
Download-Size: 23,3 kB
APT-Sources: http://ftp.de.debian.org/debian testing/main amd64 Packages
Description: Python 3 SOCKS client module
 This module was designed to allow developers of Python
 software that uses the Internet or another TCP/IP-based
 network to add support for connection through a SOCKS proxy
 server with as much ease as possible.
 .
 The module is also knowns as SocksiPy or PySocks.
 .
 This is the Python 3 version.



--
Regards
Carsten



Bug#1078518: ITP: python-whey-pth -- Extension for Whey to support .pth files

2024-08-11 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-whey-pth
  Version : 0.0.6
  Upstream Contact: Dominic Davis-Foster 
* URL : https://github.com/repo-helper/whey-pth
* License : Expat
  Programming Lang: Python
  Description : Extension to Whey to support .pth files

 whey-pth adds the ability to support site-specific paths through .pth files if
 the Whey library is used.

This package extends python3-whey and is a build dependency for
sphinx-jinja2-compat which then is a build dependency for sphinx toolbox
where Kathara Sasikumar and I do work on right now.

I plan to maintin this packagae within the DPT.



Bug#1078788: ITP: sphinx-removed-in -- Sphinx extension recognizes *removed[-in] directives

2024-08-15 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: sphinx-removed-in
  Version : 0.2.3
  Upstream Contact: Alexander Todorov 
* URL : https://github.com/MrSenko/sphinx-removed-in
* License : BSD-3-clause
  Programming Lang: Python
  Description : Sphinx extension recognizes *removed[-in] directives

 This Sphinx extension recognizes the .. versionremoved:: and
 .. removed-in:: directives. These are missing from Sphinx'es core markup.

This package is a dependency for python-sphobjinv ITP #1078565
https://bugs.debian.org/1078565

The maintenance of the package will happen within the DPT.



Bug#703226: reassign ITP patchwork

2014-08-22 Thread Carsten Schoenert
owner 703226 arturo.borrero.g...@gmail.com
thanks

Hello Arturo,

On Wed, Aug 20, 2014 at 05:53:50PM +0200, Arturo Borrero Gonzalez wrote:
> I will try to package it in upcoming weeks.
> 
> If you want, I can contact you when that happen, so you can have a
> preview of the package before the release.

that sounds fine to me.
I will try to contact Jeremy and ask him to overtake the old patch from
the patchqueue. The patch adds some simple error checking. The patch
isn't originally from me, Guido Guenther was helping me in the past.

Locally I have done in the past some trying to use debconf and
dbconfig-common for automatic configuration of the package while
installation. But especially dbconfig-common is still a mystery to me.

In general I was thinking about splitting the source package into at
last two binary packages (one for mysql and the other for postgresql
backend) but make it possible to setup more than one instance.
In theory a sqlite backend is also possible but this would be not really
performant, so this maybe only useful for testing stuf without the big
databases. I also have no nowing about usage of mariadb or so.

I'm interested in co maintainig the package, but currently I simply have
not enough time bring the package in a first state for releasing.

So if you have forther question or little testing tasks I'm willing to
help. Do not bother to contact me directly.

PS: I was free to set you as new owner for this ITP.

regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140823065017.ga23...@x201s.cruise.homelinux.net



Bug#692984: (no subject)

2014-09-12 Thread Carsten Schoenert
659291sub...@bugs.debian.org, 659291-d...@bugs.debian.org,
705488sub...@bugs.debian.org, 705488-d...@bugs.debian.org,
Cc: cont...@bugs.debian.org
Bcc: 
Subject: Closing RFP: sogo-connector -- full DAV client for Thunderbird/IceDove
Reply-To: 
In-Reply-To: <1406372094-2616-bts-lu...@debian.org>

Version: 24.0.5-1

Hello there,

now the sogo-connector package is accepted by the ftp-master team and
currently available in the experimental repository, I will close this
various RFP's.

Sogo has released version 24.0.6 in the between times. As soon as
possible I will prepare a new upload after my holidays.

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140912170250.ga1...@jessie.cruise.homelinux.net



Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

2023-05-26 Thread Carsten Schoenert
Since my last email about the status usptream did finalize the first
version 3.5.x.

One major release goal was the moving to the OpenAPI 3.0 spec, which
means a switching of the B-D drf-yasg [1] to drf-spectacular-sidecar [2].

>From a packaging POV the new dependency has the quit ethe same issues as
the olde ones, also drf-spectacular-sidecar use precompiled minimized JS
libraries which are not easy rebuildable as no source of the used data
is included in the upstream project. Also it's unclear right now how we
might get the correct sources to recompile the files.

Besides that there are no new additionl Debian packages needed to get a
recent version of NetBox build and packaged. I was able to update the
Graphene related packages in Debian to the most recent versions.

The nearly similar problem to rebuild the minimized files in the NetBox
source is still not solved, I haven't figured out yet how to do this.

[1] https://github.com/axnsan12/drf-yasg
[2] https://github.com/tfranzel/drf-spectacular-sidecar

Regards
Carsten



Bug#1037009: ITP: python-drf-spectacular-sidecar-nonfree -- Serve builds of Swagger UI and Redoc for Django REST framework

2023-06-01 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-drf-spectacular-sidecar-nonfree
  Version : 2023.5.1
  Upstream Contact: T. Franzel 
* URL : https://github.com/tfranzel/drf-spectacular-sidecar
* License : Apache-2.0, BSD-3, MIT/X
  Programming Lang: Python, JS, CSS
  Description : Serve builds of Swagger UI and Redoc for Django REST 
framework

Serve self-contained distribution builds of Swagger UI and Redoc with
Django either via runserver or collectstatic.

This Django app is an optional addition to drf-spectacular, but does not
depend on it. It may also be used independently.
It uses parts of 
Swagger UI version 4.18.3
Redoc version 2.0.0

The pulled in files for Swager-UI und Redoc are fetched from jsdelivr
and are unfortunately only the minimized parts that probbaly make the
package non-free as I'm unable to rebuild them.
.
The source for Redoc is available from
https://github.com/Redocly/redoc
but isn't packaged or available in some form in Debian.

The same is true for Swagger UI, the source is also avaialbe on GitHub
https://github.com/swagger-api/swagger-ui

So far also no Debian packages are created yet for Swagger-UI which
could be used to rebuild or reference the used minimized files in
drf-spectacular-sidecar.

This package is new dependency for NetBox (see ITP
https://bugs.debian.org/1017079) as since version 3.5.0 NetBox Upstream
has moved over to support using the OpenAPI 3.0 spec to generate the
REST API schema.

I plan to maintain the package within the an Debian Python Team.
As like for NetBox I appreciate any help around how the minimized files
could be rebuild so the package wouldn't needed to be placed in
non-free.

Regards
Carsten



Bug#1037085: RFP: strawberry-graphql -- GraphQL library for Python that leverages type annotations

2023-06-03 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist

* Package name: strawberry-graphql
  Version : 0.180.5
  Upstream Contact: Patrick Arminio 
* URL : https://github.com/strawberry-graphql/strawberry
* License : Expat
  Programming Lang: Python
  Description : GraphQL library for Python that leverages type annotations

Strawberry is a new GraphQL library for Python 3, inspired by
dataclasses. One of its goals is to provide a great developer experience
for both GraphQL beginners and advanced users.

Strawberry is a code-first GraphQL server library that uses Python type
annotations to define GraphQL types. This allows you to focus more on how
you can integrate one ore more DBs into your workflow and less on the
idiosyncrasies of GraphQL itself.

This library is a upcomming build and package dependency for NetBox (see
ITP https://bugs.debian.org/1017079).



Bug#1038812: Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

2023-07-23 Thread Carsten Schoenert

Hello Daniel,

Am 22.07.23 um 19:49 schrieb Daniel Kahn Gillmor:

Control: block 1041409 by 1038812

Hi all--

Thanks for noticing this.  Putting rnp 0.17.0 in the archive will
require sexpp to land in the archive as well, but has been in in NEW for
a few weeks (see #1038812).


I've currently switched the build for Thunderbird to use the internal 
version of RNP so the usage of the PGP functions is available again and 
I plan to upload the current version of 115.0.1 later the day again to 
experimental. We still have a few FTBFS issues within some RC platforms 
to solve. Once these problems are gone I wanted to upload 115.x to unstable.


Maybe Thorsten can have a look at the package sexpp within the NEW queue?


   --dkg

On Tue 2023-07-18 19:06:58 +0200, Carsten Schoenert wrote:

Hi Alper,

Am 18.07.23 um 17:20 schrieb Alper Nebi Yasak:

I decided to upgrade Thunderbird to the version in experimental, and
noticed that its OpenPGP functionality is completely broken: the Key
Manager is empty, and it doesn't even attempt to decrypt/verify
encrypted/signed messages (at least over external gnupg).


ha, by accident I noticed the described behavior just a few hour ago too!
Thanks for trying out Thunderbird from experimental, I expect we will
find a few more glitches like that.


The "Troubleshooting Information" page says the expected minimum version
for the RNP library is 0.17.0, where I had 0.16.3-1 installed as
currently in unstable.


Unfortunately the Thunderbird build system does not do a really good job
on detecting required versions for libraries or equal. And it's mostly
difficult to detect such version bumps by reviewing manually changes
after importing a new version.


Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I
tried installing that. But that doesn't work either, apparently its
source is older than 0.16.1? (Also see bug #1031363).

So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently
unversioned), but no such version is in Debian yet. I got it to work by
sloppily packaging the newer source. (The proper package may take a bit,
has a new dependency apparently in NEW -- I'm CC-ing the maintainer.)


Your analysis is correct, Thunderbird will need a version constrain on
librnp0. But this requires the package to be available at least in
experimental.

I'll do some work around this and change the build system while
preparing the next upload so it is using the internal shipped librnp
version until Daniel has uploaded a newer version.

--
Regards
Carsten


--
Regards
Carsten



Bug#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

2023-09-08 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist

* Package name: esbuild-sass-plugin
  Version : 2.15.0
  Upstream Contact: Gianluca Romeo 
* URL : https://github.com/glromeo/esbuild-sass-plugin
* License : MIT/X
  Programming Lang: Javescript
  Description : Plugin for esbuild to handle Sass & SCSS files

An esbuild plugin for loading Sass/SCSS files using the CSS content type.

This plugin was forked from esbuild-sass-plugin to facilitate migrations
from Webpack. Libraries that rely on sass-loader's import resolution
logic should mostly just work.

Features:
* PostCSS & CSS modules
* support for constructable stylesheet to be used in custom elements
  or dynamic style to be added to the html page
* uses the new Dart Sass Js API.
* caching
* url rewriting
* pre-compiling (to add global resources to the sass files)



Bug#1051758: ITP: python-ruyaml -- YAML 1.2 loader/dumper package for Python

2023-09-12 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-ruyaml
  Version : 0.91.0
  Upstream Contact: Anthon van der Neut, Ruamel bvba 

Sorin Sbarnea 
* URL : https://github.com/pycontribs/ruyaml
* License : MIT
  Programming Lang: Python
  Description : YAML 1.2 loader/dumper package for Python

 The ruyaml package is a fork of ruamel.yaml aimed to made in order to secure
 the future of the library, mainly by having a pool of maintainers and can be
 used as a drop-in replacement for python3-ruamel.yaml.

This package is a dependency for yamlfix (a simple opinionated yaml
formatter that keeps your comments) which I intend to package to.

Packaging will happen within the Debian Python Team.



Bug#1051978: ITP: python-yamlfix -- Simple opionated yaml formatter that keeps your comments

2023-09-15 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-yamlfix
  Version : 1.13.0
  Upstream Contact: Lyz 
* URL : https://github.com/lyz-code/yamlfix
* License : GPL-3
  Programming Lang: Python
  Description : Simple opionated yaml formatter that keeps your comments

 yamlfix is a Python based YAML file formatter which will fix any known
 formatting issue within your YAML files automatically.
 .
 It can read configuration settings from pyproject.toml, from configuration
 files or environment variables while it is called from the CLI or by
 including as Python library.
 .
 Main feature are:
  * Add the header --- to your file.
  * Correct truthy strings: 'True' -> true, 'no' -> 'false'
  * Remove unnecessary apostrophes:
title: 'Why we sleep' -> title: Why we sleep.
  * Correct comments
  * Ensure that there is exactly one newline at the end of each file, to
comply with the POSIX standard.
  * Split long lines.
  * Respect Jinja2 syntax.
  * Convert short lists to flow-style list: [item, item]
  * Convert lists longer than line-width to block-style

This package will get maintained within the Debian Python Team.



Bug#1023891: ITP: mkdocs-literate-nav -- MkDocs extension to specify the navigation in Markdown

2022-11-12 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocs-literate-nav
  Version : 0.5.0
  Upstream Author : Oleh Prypin 
* URL : https://github.com/oprypin/mkdocs-literate-nav
* License : MIT/Expat
  Programming Lang: Python
  Description : MkDocs extension to specify the navigation in Markdown

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains the mkdocs-literate-nav extension, which allows one
 to use Markdown instead of YAML to define a navigation structure within
 your MkDocs based documentation files.

This package is a new additional build requirement for the documentation
of the MkDocs project itself since a few versions. But is also used by
some other MkDocs based project documentations.

It will be maintained within the Debian Python Team.



Bug#1023892: ITP: markdown-callouts -- Python-Markdown extension adding a new block-level syntax

2022-11-12 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: markdown-callouts
  Version : 0.3.0
  Upstream Author : Oleh Prypin 
* URL : https://github.com/oprypin/markdown-callouts
* License : MIT/Expat
  Programming Lang: Python
  Description : Python-Markdown extension adding a new block-level syntax

 This package extends the functionality of Python Markdown by turning a
 paragraph of text into a block that's specially highlighted and set apart from
 the rest of the text.
 .
 This extension produces the same results as the admonition extension, but with
 a syntax that is much less intrusive and has a very reasonable fallback look
 for "vanilla" renderers.

This package is a build dependency for mkdocs-literate-nav (ITP
#1023891).

It will be maintained within the Debian Python Team.



Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

2022-12-17 Thread Carsten Schoenert
Upstream has released version 3.4.0 recently.

https://netbox.dev/announcements/netbox-3.4.0-released/

A major change is dropping a version constrain on the depending package
graphene_django < 3.

https://github.com/netbox-community/netbox/commit/bbc68f948453801e44bea8b37702d5409a55c52e#diff-b8c805f9b40de096ba79f0019f8006e17731254bd521b29410a1c9574377b8d7

graphene_django is packaged in Debian by src:django-graphene, but
currently there is only version 2.15.0-2 available in testing/unstable.

I've looked at this package to get the recent version packaged but there
is some work to do get this package updated to 3.0.0. Also the resulting
binary package dependencies would need to get an coordinated upload to
unstable.

But as due the nature of the upstream NetBox package and it's quick and
rapid development it would currently make less sense to try hard to get
NetBox into bookworm, we can always provide recent version by backports.

Currently I'll focus on get the Python related graphene packages updated
for bookworm to there current upstream versions.
 
Regards
Carsten



Bug#1026261: ITP: markdown-exec -- Utilities to execute code blocks in Markdown files

2022-12-17 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: markdown-exec
  Version : 1.0.0
  Upstream Contact: Timothée Mazzucotelli 
* URL : https://pawamoy.github.io/markdown-exec
* License : ISC
  Programming Lang: Python
  Description : Utilities to execute code blocks in Markdown files

 This package enhances the functionality of PyMdown Extensions (provided
 within Debian as package python3-pymdownx). You can use markdown-exec
 if you write e.g a Python code block that computes some HTML and you want
 to place the generated HTML within a code block.

This package is new build dependency for mkdocstrings >= 0.19.1

It will be maintained within the Debian Python Team.


Bug#1028188: ITP: python-validate-pyproject -- Automated checks on pyproject.toml by JSON Schema definitions

2023-01-08 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-validate-pyproject
  Version : 0.10.1
  Upstream Contact: Anderson Bravalheri 
* URL : https://github.com/abravalheri/validate-pyproject
* License : BSD, MIT, MPL-2.0
  Programming Lang: Python
  Description : Automated checks on pyproject.toml by JSON Schema 
definitions

 With the approval of PEP 517 and PEP 518, the Python community shifted
 towards a strong focus on standardisation for packaging software, which
 allows more freedom when choosing tools during development and make sure
 packages created using different technologies can interoperate without the
 need for custom installation procedures.
 .
 This shift became even more clear when PEP 621 was also approved, as a
 standardised way of specifying project metadata and dependencies.
 .
 validate-pyproject was born in this context, with the mission of validating
 pyproject.toml files, and make sure they are compliant with the standards
 and PEPs. Behind the scenes, validate-pyproject relies on JSON Schema files,
 which, in turn, are also a standardised way of checking if a given data
 structure complies with a certain specification.


This package is a dependency for pdm-backend (not yet filed a ITP) and
will be maintained within the Debian Python team.

Upstream uses a vendored version of fastjsonschema shipped in the folder
src/validate_pyproject/_vendor/. The reasoning isn't currently clear why
this is needed. Due this vendoring there are multiple licenses comes to
play.
I've tried to entagle this vendoring but hadn't luck until yet.

pdm-backend calles itself it is the successor for pdm-pep517 but hasn't
reached a stable version number yet.



Bug#1028365: ITP: python-covdefaults -- coverage plugin to provide sensible default settings

2023-01-10 Thread Carsten Schoenert

Hello Josenilson,

Am 10.01.23 um 02:20 schrieb Josenilson Ferreira da Silva:

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-covdefaults
   Version : 2.2.2
   Upstream Contact: Anthony Sottile 
* URL : https://github.com/asottile/covdefaults
* License : MIT/expat
   Programming Lang: Python
   Description : coverage plugin to provide sensible default settings


default settings for what?

Could you please be a bit more informative what your ITPs and the 
package you want to introduce are intended for?
Your last ITPs report are at a bare minimum with the information about 
the package.


It's not useful if fellow maintainers need to first do some research on 
their own by navigate to the upstream project site to see what the 
software or tool is doing.
We are depend on information for the things we do, so please be smart 
and take some more minutes to write up the ITP. Thanks!


--
Regards
Carsten



Bug#1054384: ITP: art/6.1-1 --ASCII art

2023-10-22 Thread Carsten Schoenert

Hello Yogeswaran,

Am 23.10.23 um 02:33 schrieb Yogeswaran Umasankar:

* Package name     : art
     Version          : 6.1-1
     Upstream contact : Sepand Haghighi 
   * URL              : https://github.com/sepandhaghighi/art
   * License          : MIT
   * Vcs              : https://salsa.debian.org/NGC2023/art
     Section          : python
     Description: ASCII art


the name 'art' is a very generic name, I suggest to use python-art 
according the source is a python library and a similar functionality 
could be also be provided by other programming languages.


The same is true for the binary package name, usually and mostly the 
package name is prefixed by 'python3-'.


PS: Please use reportbug to write your ITPs! It is setting all headers 
correctly.

https://wiki.debian.org/reportbug

--
Regards
Carsten Schönert



Bug#1058036: ITP: blanket -- Listen to different sounds

2023-12-11 Thread Carsten Schoenert

Hello Danial,

Am 11.12.23 um 14:06 schrieb Danial Behzadi:

Package: wnpp
Severity: wishlist
Owner: Danial Behzadi 
X-Debbugs-Cc: debian-de...@lists.debian.org, dani.be...@ubuntu.com

* Package name: blanket
   Version : 0.6.0
   Upstream Contact: Rafael Mardojai CM 
* URL : https://github.com/rafaelmardojai/blanket
* License : GPL-3+
   Programming Lang: Python
   Description : Listen to different sounds

Improve focus and increase your productivity by listening to different
sounds. Or allows you to fall asleep in a noisy environment.


even after visiting the upstream home I've no real clue what this 
package is about.
Seems the package description can be a lot improved and not just done by 
c&p!? :-)


--
Regards
Carsten



Bug#1062655: O: libcoap3 -- C-Implementation of CoAP - libraries API version 3

2024-02-02 Thread Carsten Schoenert
Package: wnpp
Severity: normal
X-Debbugs-Cc: libco...@packages.debian.org
Control: affects -1 + src:libcoap3

I intend to orphan the libcoap3 package.

The package description is:
 Lightweight application-protocol for devices that are constrained their
 resources such as computing power, RF range, memory, bandwidth, or network
 packet sizes. This protocol, CoAP, is developed in the IETF working group
 "CoRE",  and was
 standardized in RFC 7252.
 .
 The libcoap library v3 has DTLS functionality included based on TLS
 functions provided by GnuTLS or OpenSSL with enhanced behavior to the
 previous API version.
 .
 This package contains the various libcoap libraries based on API v3 with
 and without DTLS functionality.



Bug#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

2024-02-11 Thread Carsten Schoenert
The list of deps isn't that long, but there are some other packages need
to be around before esbuild-sass-plugin can be packaged.

$ date
Mo 12. Feb 08:15:18 CET 2024
$ npm2deb depends -b -r esbuild-sass-plugin
Dependencies:
NPM   Debian
esbuild-sass-plugin (3.0.0)   None
├─ resolve (^1.22.6)  node-resolve 
(1.22.8+~cs5.34.15-2)
└─ sass-embedded (^1.70.0)None
   ├─ @bufbuild/protobuf (^1.0.0) None
   ├─ buffer-builder (^0.2.0) None
   ├─ immutable (^4.0.0)  node-immutable (4.3.4-1)
   ├─ rxjs (^7.4.0)   None
   │  └─ tslib (^2.1.0)   node-tslib (2.4.1-1)
   ├─ supports-color (^8.1.1) node-supports-color 
(8.1.1+~8.1.1-1)
   └─ varint (^6.0.0) None



Bug#1057386: [Pkg-electronics-devel] imsprog , #1057386

2024-02-15 Thread Carsten Schoenert

Hello Ivan,

Am 14.02.24 um 09:07 schrieb Kosolapov Ivan:

Good day!
I am developer of the imsprog package.
(https://mentors.debian.net/package/imsprog , #1057386)
  This is a GUI tool for programming BIOS chips, automotive memory, 
satellite and TV receiver memory chips and much more using the popular 
CH341a programmer. It has no analogues in linux-systems. By many 
parameters it surpasses flashrom, because IMSProg can program not only 
SPI FLASH ROM chips, but also chips of I2C and MicroWire series, and 
also uses graphical interface. Some IMSProg functions are unique, such 
as reading the SFDP register and the ability to modify the chip's system 
registers.
I would be very grateful if this package could appear in Debian. I need 
a sponsor.


that looks like an interesting package.
I'm will to have a look and also to sponsor later potentially.

--
Regards
Carsten



Bug#1057386: Upload of imsprog

2024-02-20 Thread Carsten Schoenert

Hello Fabio,

Am 20.02.24 um 10:28 schrieb Fabio Fantoni:

Hi, is it possible to upload this shortly to try to include before the
feature freeze on Ubuntu 24.04? (February 29th)

I helped to improve the packaging, and now seems ready to me, but I'm
only DM and I can't upload new packages.

2 DD did a review on mentors over the past weeks and the recommended
changes have been made, but it seems they haven't had time to review it
again recently.


in a short term I need to answer no, I can't process this RFP on a quick 
run.
The uploader is responsible for the package and the upload itself, no 
matter if other DDs did have already done a review of the package in 
detail. Before the weekend I wont have time to dig into the current 
packaging.


--
Regards
Carsten



Bug#1057386: Subject: ITP: imsprog -- linux chip programmer for CH341a devices

2024-03-03 Thread Carsten Schoenert
Hello Mikhail,

Am Mon, Dec 04, 2023 at 01:48:14PM +0300 schrieb Mikhail Medvedev:
> Package: wnpp
> Severity: wishlist
> Owner: Mikhail Medvedev 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : imsprog
>   Version : 1.1.2-12
>   Upstream Author : Mikhail Medvedev 
> * URL : https://github.com/bigbigmdm/IMSProg
> * License : GPL-3
>   Programming Lang: C, C++, Bash
>   Description : GUI Chip programmer for CH341a devices
> 
> 
> IMSProg  -  QT-based  GUI  application  -  I2C,  MicroWire and SPI EEP‐
> ROM/Flash chip programmer for CH341a devices. The IMSProm is a free I2C
> EEPROM  programmer tool for CH341A device based on QhexEdit2 and modify
> SNANDer programmer.
> 
>  IMSProg consists of three executable modules:
> 
>  1. IMSProg - the chip programmer itself.
> 
>  2. IMSProg_editor - chip database editor.
> 
>  3. IMSProg_database_update - online chip database update from  the ex‐
> ternal web-server.

the content and the build of the package is fine, also no real blockers
through Lintian vissible.

Except this warning:

W: imsprog: appstream-metadata-missing-modalias-provide 
usr/lib/udev/rules.d/99-CH341.rules

I'm not thiat deep in the internals of imsprog and maybe this is a false
positive, if not have a loo at these resources to hopefully get this
warning fixed:

>From https://freedesktop.org/software/appstream/docs/chap-Metadata.html

...


A modalias glob representing the hardware types (for example USB,
PCI, ACPI, DMI) this component handles. Useful for installing
printer drivers or other USB protocol drivers for smartphones,
firmware, and out of tree kernel drivers.
...

In the Debian Wiki
https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

The Lintian warning should get addressed in a further new release.

For now to me it's o.k. to upload the current version 1.3.2-1

Regrads
Carsten



Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices

2024-03-03 Thread Carsten Schoenert

Hello Mikhail,

Am 03.03.24 um 20:35 schrieb Kosolapov Ivan:

Hello, Carsten!
Regarding W: imsprog: appstream-metadata-missing-modalias:
I was already informed yesterday by Alt-Linux colleagues about the 
erroneous comment format in file 99-CH341.rules.
I have already fixed it in 
https://github.com/bigbigmdm/IMSProg/commit/8be1584358b6c7a4cb0224bc813e3e284d62cb42

Is there an urgent need for a new release because of this fix?


I think no, but I can upload a newer version to NEW every time.
It might be that a FTP-Admin is "complaining" about that warning, but a 
reject of the package should not happen.


My guess is that a review of the package will take a bit of time, I'd be 
surprised if it will get processed within of days.
So proceed with your usual development process and ping me once you 
released a new version which has fix included. I'll prepare a new upload 
then.


--
Regards
Carsten



Bug#1065749: ITP: flask-debugtoolbar -- Debugging toolbar overlay information for Flask applications

2024-03-09 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: flask-debugtoolbar
  Version : 0.14.1
  Upstream Contact: Pallets 
* URL : https://github.com/pallets-eco/flask-debugtoolbar
* License : BSD-3-clause
  Programming Lang: Python, JS
  Description : Debugging toolbar overlay information for Flask applications

 Flask is a micro web framework for Python based on Werkzeug, Jinja 2 and good
 intentions.
 .
 This python3 package adds a toolbar overlay to Flask applications containing
 useful information for debugging.

This package is the equivalent of python-django-debug-toolbar but for
Flask.

I intend to maintain this packge within the DPT.



Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

2024-03-23 Thread Carsten Schoenert

Hello Matthias,

Am 23.03.24 um 16:51 schrieb Matthias Geiger:

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, werdah...@riseup.net

* Package name: kicad-gruvbox-theme
   Version : 1.1.0
   Upstream Contact: Alexander Brevig
* URL : https://github.com/AlexanderBrevig/kicad-gruvbox-theme
* License : MIT
   Programming Lang: n/a
   Description : Gruvbox colorscheme for KiCadi

A simple gruvbox colorscheme for the EESchema and PCBNew editors within
KiCad. KiCad 8 allows for the system-wide installation of
colorschemes, thus ITP'ing now.


how is this system wide installation intended to work.

Even the upstream project site states the installation needs to happen 
into ~/.config/kicad/colors or ~/.config/kicad/6.0/colors (besides it 
uses the older version 6.0 as user folder)


As long as I follow this feature I'm not aware that any system wide 
installation of themes is now possible.


Given it is possible, how the internal Plugin and Content Management 
will handle this?


--
Regards
Carsten



Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

2024-03-23 Thread Carsten Schoenert

Hello Matthias,

Am 23.03.24 um 17:40 schrieb Matthias Geiger:

Hi Carsten,

thanks for maintaining KiCad. What you mentioned is true for Kicad <=
7.0. With 8.0 a change landed enabling installation of colorthemes
system-wide  (see https://gitlab.com/kicad/code/kicad/-/issues/15920).

I already created a package and installed it and it works as intended.
Since this does not touch user files this conforms to Debian policy.
The plugin manager does not show this scheme as installed since it only
looks for user themes.


nice, o.k., then upstream has still some work to do. :-)

Would it not better creating one src:package which would package the 
various themes all together that are out there? e.g. named kicad-themes


I dislike a bit multiple packages that a user needs to know (and to 
install then) if all could get packaged into one.
There could be of course also a virtual package kicad-themes which pulls 
in the installation of all the real other theme packages.


Most of the other themes are not under heavy development and will only 
change randomly.
Downside otoh is you will need to run a own scripting to detect changes. 
Is also not that complicated.


But that's up to you if you can agree on my ideas.

--
Regards
Carsten



Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

2024-03-23 Thread Carsten Schoenert

Am 23.03.24 um 18:29 schrieb Matthias Geiger:

I agree that packaging all themes is doable. However, how would I create
a src: package with different upstream tarballs? I could use some help
with that. Providing a virtual package for all themes is also a good idea.


To me you don't need multiple tarballs to archive the goal, you could 
add all the various sources into one tarball. Using so called component 
tarballs brings no gain to me, the usage of them also have 
disadvantages. How these tarballs are getting used did Raphael Herzog 
explain in one of his blog posts [1].


I think you can go like this, arrange the folders and finally create a 
tarball of the top folder.



.
├── kicad-theme1
├── kicad-theme2
├── kicad-theme3
└── kicad-theme...


The creation of this tarball can be done by a script living in the 
debian/ folder. Adding later another theme is simply adding one more 
folder and adjusting d/rules, d/copyright and sequencers maybe.


If you want to create various binary packages adding a new themes will 
require a new binary upload to NEW then. This is no issue, such uploads 
get processed much quicker than a complete new src package.



Would you be ok with this package being maintained under the Electronics
Team ?


Sure, why not. Would be quite logical to place it here.

[1] 
https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/


--
Regards
Carsten



Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices

2024-03-26 Thread Carsten Schoenert

Hello Mikhail,

Am 26.03.24 um 08:37 schrieb Kosolapov Ivan:

Hello, Carsten!
I have built a new version of IMSProg (v1.3.3).
Can you please tell me how I can get this version to you? Do I have to 
upload the new version on mentors.debian or do you get it from GitHub?


I pulled the git tree from GitHub and build the package from that source.

I can build an updated version from the same tree again.
The current entries in debian/latest looking an bit odd and chaotic.

* commit 8fa592e6b5eaa5332580ab0b1cbe7dca766dc3dd (HEAD -> 
debian/latest, origin/debian/latest)

| Author: Mikhail Medvedev 
| Date:   Mon Mar 25 18:33:32 2024 +0300
|
| a new version has been built
|
* commit 21f8b17153bba0472c68f14d0382f3d3d50aa0a6
| Author: Mikhail Medvedev 
| Date:   Mon Mar 25 16:23:43 2024 +0300
|
| Release description has been changed
|
* commit d58dc3f6be7de4b2893f5db819875803c86f769b
| Author: Mikhail Medvedev 
| Date:   Mon Mar 25 15:17:34 2024 +0300
|
| Modify changelog
|
*   commit b9cf508be810d086dfe20a8c1fa3e62c86d02be8
|\  Merge: 347b4bc d8b79c5
| | Author: Mikhail Medvedev 
| | Date:   Mon Mar 25 15:14:51 2024 +0300
| |
| | Update upstream source from tag 'v1.3.3'
| |
| | Update to upstream version '1.3.3'
| | with Debian dir d492f797a1719579b5b6fe214f0a075ca9a1903a
| |
| * commit d8b79c5bfeec760c4ab857072f4fca33e8bd5c74 (tag: v1.3.3, 
origin/main, origin/HEAD)

| | Author: Mikhail Medvedev 
| | Date:   Mon Mar 25 14:47:05 2024 +0300
| |
| | added status register form for 95xxx, 25xxx chips

Can you rebase the last tree commits into one and keep at lest the 
following lines in the changelog? (Once the package is within the 
archive of course such rebasing should not happen anymore. Have a look 
into existing changelog entries from other files for examples how to 
write the entries.)


  * New upstream release 1.3.3
  * Initial release (Closes: #1057386)

The last entry is needed with every new upstream version that is getting 
uploaded for automatic closing the ITP bug report if the FTP master 
chose to accept the package.


--
Regards
Carsten



Bug#987417: ITP: libcoap3 -- C-Implementation of CoAP, API version 3

2021-04-23 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libcoap3
  Version : 4.3.0~rc2
  Upstream Author : Olaf Bergmann 
* URL : https://libcoap.net
* License : BSD-2-clause
  Programming Lang: C
  Description : C-Implementation of CoAP, API version 3

Lightweight application-protocol for devices that are constrained their
resources such as computing power, RF range, memory, bandwidth, or
network packet sizes. This protocol, CoAP, is developed in the IETF
working group "CoRE", <http://6lowapp.net> and was standardized in RFC
7252.

The libcoap library has been evolved and has now reached the API version
3 which includes changes that makes the library not backward compatible.
To keep the packages from libcoap3 co-installable to the current
upstream version of libcoap will go into a new source package.

The packaging will be done within the IoT packaging group as a team
managed package.

Regards
Carsten



Bug#988971: ITP: python-django-crispy-forms-foundation -- django-crispy-forms layout objects for Foundation for sites

2021-05-22 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-django-crispy-forms-foundation
  Version : 0.8.0
  Upstream Author : David THENON 
* URL : https://github.com/sveetch/crispy-forms-foundation
* License : Expat
  Programming Lang: Python
  Description : django-crispy-forms layout objects for Foundation for sites

 This is a Django application to add django-crispy-forms layout objects for
 the CSS framework Foundation for sites. It depends on the
 python3-crispy-forms library.
 .
 django-crispy-forms provides you with a |crispy filter and {% crispy %} tag
 that will let you control the rendering behavior of your Django forms in a
 very elegant and DRY way. Have full control without writing custom form
 templates. All this without breaking the standard way of doing things in
 Django, so it plays nice with any other form application.
 .
 django-crispy-forms supports several frontend frameworks, such as Twitter
 Bootstrap (versions 3 and 4), Uni-form and Foundation. You can also easily
 adapt your custom company's one, creating your own, see the docs for more
 information. You can easily switch among them using CRISPY_TEMPLATE_PACK
 setting variable.

This package is a depending package we use at our infrastructure on my
day job.
It will be maintained within the DPT.



Bug#989527: ITP: python-markuppy -- module to generate HTML/XML content

2021-06-06 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-markuppy
  Version : 1.14
  Upstream Author : Tyler Bakke 
* URL : https://pypi.org/project/MarkupPy
* License : MIT public-domain
  Programming Lang: Python
  Description : module to generate HTML/XML content

 MarkupPy is a Python module that attempts to make it easier to generate
 HTML/XML from a Python program in an intuitive, lightweight,
 customizable and pythonic way.

MarkupPy is derived from markup.py.
There is a GitHub project for this library, unfortunately it's lagging
far behind the visible data on PyPi.

https://github.com/tylerbakke/MarkupPy

This library is a new build and install dependency for python3-tablib
which I intend updating to the current usptream version.

This package will get maintained within The Python Modules Team.



Bug#989811: ITP: python-funcy -- Collection of fancy functional tools focused on practicality

2021-06-13 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-funcy
  Version : 1.16
  Upstream Author : Alexander Schepanovski 
* URL : https://github.com/Suor/funcy
* License : BSD-3-clause, MIT
  Programming Lang: Python
  Description : Collection of fancy functional tools focused on practicality

 Funcy is designed to be a layer of functional tools over Python.
 It provides some possible often wanted functionality like:
  * Merge collections of same type (works for dicts, sets, lists, tuples,
iterators and even strings).
  * Walk through collection, creating its transform (like map but preserves
type).
  * Select a part of collection.
  * Manipulate sequences.
  * And functions.
  * CreAbstract control flowate decorators easily.
  * Abstract control flow.
  * Ease debugging.

This package is a (build) dependency for django-cachops which hasn't a ITP
yet. django-cacheops itself is a dependency for netbox I consider to
package.

The package will get maintained within the Debian Python Team.



Bug#990085: ITP: django-rq -- Django integration with RQ (Redis Queue)

2021-06-20 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: django-rq
  Version : 2.4.1
  Upstream Author : Selwin Ong 
* URL : https://github.com/rq/django-rq
* License : MIT
  Programming Lang: Python
  Description : Django integration with RQ (Redis Queue)

 Django-RQ is a simple app that allows you to configure your queues in django's
 settings.py and easily use them in your project.

This package is a (build) dependency for netbox I consider to package.

The package will get maintained within the Debian Python Team.



Bug#990289: ITP: django-pglocks -- Django based context manager for PostgreSQL advisory locks

2021-06-24 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: django-pglocks
  Version : 1.0.4
  Upstream Author : Christophe Pettus 
* URL : https://github.com/Xof/django-pglocks
* License : MIT
  Programming Lang: Python
  Description : Django based context manager for PostgreSQL advisory locks

 django-pglocks is a context manager for Django.
 Advisory locks are application-level locks that are acquired and released
 purely by the client of the database; PostgreSQL never acquires them on its
 own. They are very useful as a way of signalling to other sessions that a
 higher-level resource than a single row is in use, without having to lock an
 entire table or some other structure.
 
 It's entirely up to the application to correctly acquire the right lock.
 
 Advisory locks are either session locks or transaction locks. A session lock
 is held until the database session disconnects (or is reset); a transaction
 lock is held until the transaction terminates.
 
 Currently, the context manager only creates session locks, as the behavior of
 a lock persisting after the context body has been exited is surprising, and
 there's no way of releasing a transaction-scope advisory lock except to exit
 the transaction.

This package is a dependency for netbox I consider to package.

The package will get maintained within the Debian Python Team.



Bug#990341: ITP: swagger-spec-validator -- Validation of Swagger specifications

2021-06-25 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: swagger-spec-validator
  Version : 2.7.3
  Upstream Author : core-servi...@yelp.com
Semir Patel 
Stephan Jaensch 
* URL : https://github.com/Yelp/swagger_spec_validator
* License : Apache-2.0
  Programming Lang: Python
  Description : Validation of Swagger specifications

 Swagger Spec Validator is a Python library that validates Swagger Specs
 against the Swagger 1.2
 (https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md)
 or Swagger 2
 (https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md)
 specification.
 The validator aims to check for full compliance with the Specification.

This package is a dependency for netbox I consider to package.

The package will get maintained within the Debian Python Team.



Bug#990420: ITP: django-cacheops -- Django app adding automatic or manual queryset caching

2021-06-28 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: django-cacheops
  Version : 6.0
  Upstream Author : Alexander Schepanovski 
* URL : https://github.com/Suor/django-cacheops
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django app adding automatic or manual queryset caching

 django-cacheops is a slick app that supports automatic or manual queryset
 caching and automatic granular event-driven invalidation.
 .
 It uses redis as backend for ORM cache and redis or filesystem for simple
 time-invalidated one.
 .
 And there is more to it:
 .
  * decorators to cache any user function or view as a queryset or by time
  * extensions for django and jinja2 templates
  * transparent transaction support
  * dog-pile prevention mechanism
  * a couple of hacks to make django faster

This package is a dependency for netbox I consider to package.
django-cacheops has build depenendency on python3-funcy which is
currently waiting in the NEW queue (see ITP #989811).

The package will get maintained within the Debian Python Team.



Bug#990874: ITP: drf-yasg-nonfree -- Yet another Swagger generator

2021-07-10 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: drf-yasg-nonfree
  Version : 1.20.0
  Upstream Author : Cristi V. 
* URL : https://github.com/axnsan12/drf-yasg
* License : BSD-3-clause
  Programming Lang: Python
  Description : Yet another Swagger generator

 Generate real Swagger/OpenAPI 2.0 specifications from a Django Rest Framework
 API.
 Features of drf-yasg:
  * full support for nested Serializers and Schemas
  * response schemas and descriptions
  * model definitions compatible with codegen tools
  * customization hooks at all points in the spec generation process
  * JSON and YAML format for spec
  * bundles latest version of swagger-ui
(https://github.com/swagger-api/swagger-ui) and redoc
(https://github.com/Rebilly/ReDoc) for viewing the generated documentation
  * schema view is cacheable out of the box
  * generated Swagger schema can be automatically validated by
swagger-spec-validator (https://github.com/Yelp/swagger_spec_validator)
  * supports Django REST Framework API versioning with URLPathVersioning
and NamespaceVersioning; other DRF or custom versioning schemes are
not currently supported

Some parts of the upstream data are shipped pre-generated within the
source, the package built isn't able to rebuild these files from source
for various reasons. Mainly because the used JS files aren't packaged
yet for Debian.
This makes the resulting package non-free from the DFSG PoV. That's why
I decided to use the suffix '-nonfree' for now. Resulting also the binary
packages will go into non-free.

If someone is willing to help making this package DFSG compatible I'd
really be glad to take such an offer.

This package is a dependency for netbox I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991679: ITP: python-text-unidecode -- most basic Python port of the Text::Unidecode Perl library

2021-07-30 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-text-unidecode
  Version : 1.3
  Upstream Author : Mikhail Korobov 
* URL : https://github.com/kmike/text-unidecode/
* License : Artistic, GPL
  Programming Lang: Python
  Description : most basic Python port of the Text::Unidecode Perl library

 This library is an alternative of other Python ports of Text::Unidecode
 (unidecode and isounidecode).
 unidecode (in Debian available as python3-unidecode) is licensed under GPL;
 isounidecode uses too much memory, and it also didn’t support Python 3 when
 text-unidecode was created.

This package is an indirect dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.


Bug#991692: ITP: python-promise -- Implementation of Promises in Python

2021-07-30 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-promise
  Version : 2.3.0
  Upstream Author : Syrus Akbary 
* URL : https://github.com/syrusakbary/promise
* License : MIT
  Programming Lang: Python
  Description : Implementation of Promises in Python

 It is a super set of Promises/A+ designed to have readable, performant code
 and to provide just the extensions that are absolutely necessary for using
 promises in Python.
 Its fully compatible with the Promises/A+ spec.

This package is an indirect dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991736: ITP: graphql-relay -- Relay Library for GraphQL Python

2021-07-31 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: graphql-relay
  Version : 3.1.0
  Upstream Author : Syrus Akbary 
* URL : https://github.com/graphql-python/graphql-relay-py
* License : MIT
  Programming Lang: Python
  Description : Relay Library for GraphQL Python

 This package contains the Relay (https://relay.dev/) library for GraphQL-core.
 .
 It allows the easy creation of Relay-compliant servers using GraphQL-core.
 GraphQL-Relay-Py is a Python port of graphql-relay-js
 (https://github.com/graphql/graphql-relay-js), while GraphQL-Core is a
 Python port of GraphQL.js (https://github.com/graphql/graphql-js), the
 reference implementation of GraphQL for JavaScript.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991740: ITP: graphql-core -- GraphQL implementation for Python

2021-07-31 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: graphql-core
  Version : 3.1.5
  Upstream Author : Christoph Zwerschke 
* URL : https://github.com/graphql-python/graphql-core
* License : MIT
  Programming Lang: Python
  Description : GraphQL implementation for Python

 GraphQL-core 3 is a Python 3.6+ port of GraphQL.js, the JavaScript reference
 implementation for GraphQL, a query language for APIs created by Facebook.
 GraphQL-core provides a reference implementation for the GraphQL
 specification but is also a useful utility for operating on GraphQL files
 and building sophisticated tools.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991775: ITP: graphene -- GraphQL Framework for Python

2021-08-01 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: graphene
  Version : 2.1.9
  Upstream Author : Syrus Akbary 
* URL : https://github.com/graphql-python/graphene
* License : MIT
  Programming Lang: Python
  Description : GraphQL Framework for Python

 Graphene is a Python library for building GraphQL schemas/types fast and
 easily.
 .
  * Easy to use: Graphene helps you use GraphQL in Python without effort.
  * Relay: Graphene has builtin support for Relay.
  * Data agnostic: Graphene supports any kind of data source: SQL (Django,
SQLAlchemy), NoSQL, custom Python objects, etc. Upstream believes
that by providing a complete API you could plug Graphene anywhere
your data lives and make your data available through GraphQL.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991812: ITP: django-graphene -- Django integration for Graphene

2021-08-02 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: django-graphene
  Version : 2.15.0
  Upstream Author : Syrus Akbary 
* URL : https://github.com/graphql-python/graphene-django
* License : MIT
  Programming Lang: Python
  Description : Django integration for Graphene

 Graphene-Django is built on top of Graphene. Graphene-Django provides some
 additional abstractions that make it easy to add GraphQL functionality to
 your Django project.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991872: ITP: python-graphene -- GraphQL Framework for Python

2021-08-04 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-graphene
  Version : 2.1.9
  Upstream Author : Syrus Akbary 
* URL : https://github.com/graphql-python/graphene
* License : MIT
  Programming Lang: Python
  Description : GraphQL Framework for Python

 Graphene is a Python library for building GraphQL schemas/types fast and
 easily.
 .
  * Easy to use: Graphene helps you use GraphQL in Python without effort.
  * Relay: Graphene has builtin support for Relay.
  * Data agnostic: Graphene supports any kind of data source: SQL (Django,
SQLAlchemy), NoSQL, custom Python objects, etc. Upstream believes
that by providing a complete API you could plug Graphene anywhere
your data lives and make your data available through GraphQL.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.

Additional information, due a mistake of me by not safely checking for
the availability of the intended source package name I raised a similar
ITP (#991775) some days ago.
Due this my upload went to the already existing source package graphene.

https://tracker.debian.org/pkg/graphene

I've requested the removal of my upload into the NEW queue.



Bug#991740: Please reject graphql-core and graphql-relay from NEW

2021-08-05 Thread Carsten Schoenert
Hi,

recently I uploaded the packages graphql-core and graphql-relay into the
NEW queue.

For the packaging I filled two ITP reports previously.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991740
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991736

While working further on the packaging for python-graphene (#991775) I
noticed that the most recent version of python-graphene isn't requiring
the latest versions of graphql-core and -relay and instead is wanting a
version 2.x (instead of 3.x) for both depending packages.

Thus it would be helpful if you could please reject graphql-core and
graphql-relay for now as this would prevent the introduction of an epoch
or some 'really+foo' syntax in this stage as I wanted to start all the
packaging stuff in experimental.
Please don't close the ITP bug reports if you do the rejects, thanks!

I'll reuse the bug reports then later by a new upload of the new
packaged versions.

Sorry for making extra work!

-- 
Regards
Carsten



Bug#992446: ITP: django-graphiql-debug-toolbar -- Django Debug Toolbar for GraphiQL IDE

2021-08-18 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: django-graphiql-debug-toolbar
  Version : 0.1.4
  Upstream Author : mongkok 
* URL : https://github.com/flavors/django-graphiql-debug-toolbar
* License : MIT
  Programming Lang: Python
  Description : Django Debug Toolbar for GraphiQL IDE

 This package adds a debug toolbar within your Django application for
 the GraphiQL IDE.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#998222: ITP: mssql-django -- Django backend for Microsoft SQL Server

2021-11-01 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mssql-django
  Version : 1.0
  Upstream Author : Microsoft 
* URL : https://github.com/microsoft/mssql-django
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django backend for Microsoft SQL Server

 This package is a fork of django-mssql-backend which isn't getting developed
 any more.
 The package provides an MSSQL database connectivity option for the Django
 Web Framework, with support for Microsoft SQL Server and Azure SQL Databases.

This package will be maintained within the Python Packaging team.



Bug#1006163: ITP: pyyaml-env-tag -- Custom YAML tag for referencing environment variables

2022-02-19 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pyyaml-env-tag
  Version : 0.1
  Upstream Author : Waylan Limberg 
* URL : https://github.com/waylan/pyyaml-env-tag
* License : MIT
  Programming Lang: Python
  Description : Custom YAML tag for referencing environment variables

 This library is the Python port of yaml-env-tag, a Ruby library to use
 referenced environment variables within YAML files.

This library is a new build dependency for recent versions of python-mkdocs.
It will be maintained under the umbrella of Debian Python Team.



Bug#1006479: ITP: mergedeep -- Deep merge function for Python

2022-02-25 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mergedeep
  Version : 1.3.4
  Upstream Author : Travis Clarke 
* URL : https://github.com/clarketm/mergedeep
* License : MIT
  Programming Lang: Python
  Description : Deep merge function for Python

 This library can help if you need to do some deep merge without mutating 
 the source dicts or while you want to deep merging into an existing dict.
 It provides various merge strategies (Replace, Additive, Typesafe replace,
 or Typesafe additive).

This package is a new build dependency for python-mkdocs and will be
maintained within the DPT.



Bug#1006480: ITP: mkdocs-redirects -- Plugin for mkdocs to create page redirects

2022-02-25 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocs-redirects
  Version : 1.0.1
  Upstream Author : Dustin Burke 
* URL : https://github.com/datarobot/mkdocs-redirects
* License : MIT
  Programming Lang: Python
  Description : Plugin for mkdocs to create page redirects

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains an addon for mkdocs to create page redirects
 (e.g. for moved/renamed pages).

This package is a new build dependency for python-mkdocs and will be
maintained within the DPT.



Bug#1006483: ITP: python3-mergedeep -- A deep merge function for Python

2022-02-26 Thread Carsten Schoenert

Hello Edward,

I've wrote an ITP for the same package shortly before your ITP:

https://bugs.debian.org/1006479

And uploaded to NEW right now.
So you shouldn't need to do any additional work, I'm happy if you want 
to do some co-maintaining and uploading for this package.


Regards
Carsten

Am 26.02.22 um 09:12 schrieb Edward Betts:

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python3-mergedeep
   Version : 1.3.4
   Upstream Author : Travis Clarke
* URL : https://github.com/clarketm/mergedeep
* License : MIT
   Programming Lang: Python
   Description : A deep merge function for Python

Includes four merge strategies:

## Replace

When destination and source keys are the same, replace
the destination value with one from source (default).

## Additive

When destination and source values are both the same additive
collection type, extend destination by adding values from source.

Additive collection types include: list, tuple, set, and Counter

## Typesafe replace
When destination and source values are of different types, raise
TypeError. Otherwise, perform a REPLACE merge.

## Typesafe additive

When destination and source values are of different types, raise
TypeError. Otherwise, perform a ADDITIVE merge.


This is a dependency of the datasette tool by Simon Willison.

I plan to maintain this package as part of the python modules team.





Bug#1008086: ITP: python-lunr -- Python implementation of Lunr.js

2022-03-22 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-lunr
  Version : 0.6.1
  Upstream Author : Yeray Diaz Diaz 
* URL : https://github.com/yeraydiazdiaz/lunr.py
* License : MIT/X, BSD
  Programming Lang: Python
  Description : Python implementation of Lunr.js

 This package includes the Python version of Lunr.js aims to bring the simple
 and powerful full text search capabilities into Python guaranteeing results as
 close as the original implementation as possible.
 .
 Lunr is a simple full text search solution for situations where deploying a
 full scale solution like Elasticsearch isn't possible, viable or you're simply
 prototyping. Lunr parses a set of documents and creates an inverted index for
 quick full text searches in the same way other more complicated solution.
 .
 The trade-off is that Lunr keeps the inverted index in memory and requires you
 to recreate or read the index at the start of your application.

This package is a new dependency for newer versions of pydoctor and will
get maintained within the DPT.

Regards
Carsten



Bug#1009221: ITP: pytkdocs -- Legacy Python handler for mkdocstrings

2022-04-08 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pytkdocs
  Version : 0.16.1
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/pytkdocs
* License : ISC
  Programming Lang: Python
  Description : Load Python objects documentation

 This Python library is used to load Python objects documentation. It accepts
 JSON on standard input and writes JSON on standard output.
 .
 It is typically used to read data from standard input while writing
 processed data line by line. Especially mkdocstrings is wanting this
 behavior.

This package is a new indirect dependency for the recent released minor
version of NetBox 3.2.x.

It will be maintained within the Debian Python Team.


Bug#1009255: ITP: mkdocs-autorefs -- Plugin for MkDocs to automatically link across pages

2022-04-09 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocs-autorefs
  Version : 0.4.1
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/autofefs
* License : ISC
  Programming Lang: Python
  Description : Plugin for MkDocs to automatically link across pages

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains an plugin for MkDocs that can add linking across the
 various sites created by MkDocs.

This package is a new indirect dependency for the recent released minor
version of NetBox 3.2.x.

It will be maintained within the Debian Python Team.


Bug#1009892: ITP: mkdocstrings -- Automatic Python documentation from sources for MkDocs

2022-04-19 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocstrings
  Version : 0.17.0
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/mkdocstrings
* License : ISC
  Programming Lang: Python
  Description : Automatic Python documentation from sources for MkDocs

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains an plugin for MkDocs to build automatic documentation
 from docstrings within your source code files.

This package is a new direct dependency for the recent released minor
version of NetBox 3.2.x.

It will be maintained within the Debian Python Team.


Bug#1010382: ITP: mkdocstrings-python-legacy -- Legacy Python handler for mkdocstrings

2022-04-29 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocstrings-python-legacy
  Version : 0.2.2
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/python-legacy
* License : ISC
  Programming Lang: Python
  Description : Legacy Python handler for mkdocstrings

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains an legacy Python handler used within mkdocstrings.

This package is a new dependency for mkdocstrings >= 0.18 which due a
split of existing legacy Python functions moved into a own library.

It will be maintained within the Debian Python Team.


Bug#1011192: ITP: python-griffe -- Signatures for entire Python programs

2022-05-17 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-griffe
  Version : 0.18.0
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/griffe
* License : ISC
  Programming Lang: Python
  Description : Signatures for entire Python programs

 Extract the structure, the frame, the skeleton of your project,
 to generate API documentation or find breaking changes in your API.

This package is a new indirect dependency for mkdocstrings >= 0.18.0
because mkdocstrings got refactored into more dedicated libraries and
tools since version 0.18.0.
In detail python-griffe is a dependency of mkdocstings-python-handlers
which itself is a dependency of mkdocstrings-python-legacy.

It will be maintained within the Debian Python Team.


Bug#1011194: ITP: mkdocstrings-python-handlers -- Python handler for mkdocstrings

2022-05-17 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkdocstrings-python-handlers
  Version : 0.6.6
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/python
* License : ISC
  Programming Lang: Python
  Description : Python handler for mkdocstrings

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains a Python handler required by various helping libraries
 around mkdocstrings.

This package is a new direct dependency for mkdocstrings >= 0.18.0
because mkdocstrings got refactored into more dedicated libraries and
tools since version 0.18.0.
In detail mkdocstings-python-handlers is a dependency of
mkdocstings-python-legacy which is now required by mkdocstrings
>= 0.18.0.

It will be maintained within the Debian Python Team.


Bug#1013194: ITP: django-rich -- Extensions for using Rich with Django

2022-06-18 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: django-rich
  Version : 1.4.0
  Upstream Author : Adam Johnson 
* URL : https://github.com/adamchainz/django-rich
* License : MIT
  Programming Lang: Python
  Description : Extensions for using Rich with Django

 Rich is a Python library for writing rich text (with color and style) to the
 terminal, and for displaying advanced content such as tables, markdown, and
 syntax highlighted code.
 .
 The djano-rich library is adding such functionality into a Django integration
 so colourized outputs and nice traceback rendering is possible.

This Django extension is an upcoming new requirement for NetBox next
minor version 3.3 (not yet released).

It will be maintained within the Debian Python Team.



Bug#1077755: ITP: python-picologging -- Fast and lightweight Python logging library

2024-08-01 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org, Kathara Sasikumar 


* Package name: python-picologging
  Version : 0.9.3
  Upstream Contact: Microsoft Corporation>
* URL : https://github.com/microsoft/picologging
* License : MIT/X, PSF-2.0
  Programming Lang: Python
  Description : Fast and lightweight Python logging library

 Picologging is a high-performance logging library for Python, it's about
 4-10x faster than the logging module in the standard library.
 .
 Picologging is designed to be used as a drop-in replacement for applications
 which already use logging, and supports the same API as the logging module.

I plan to maintin this packagae within the DPT.



Bug#774928: ITP: libcoap -- library for the CoAP protocol written in C

2015-01-09 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: libcoap
  Version : 4.1.1
  Upstream Author : Olaf Bergmann 
* URL : http://sourceforge.net/projects/libcoap/
* License : GPL2+ and BSD
  Programming Lang: C
  Description : C Library Implementation of CoAP

The libcoap is basically a C implementation of the IETF CoAP
(Constrained Application Protocol). The CoAP protocol is major
standardized by the IETF in the RFC 7252 and is a application layer
protocol for low power devices for the Internet of Things (IoT) and 
Machine to Machine (M2M) communication.

CoAP is mostly used in 6loWPAN environments. The libcoap library
provides functions to talk to such devices and makes it possible to
interact with low power IPv6 based devices.

There are some other frameworks written in Java, Python or JavaScript
that implement CoAP bindings. As far as I know there is nothing yet
packaged for the use of the CoAP protocol. That's the main reason why
I want to package and maintain the libcoap package.

Currently the upstream source is lacking some minor tweaks like
versioning of the library and also symbol versioning. The build
environment is improvable. I'm in contact with Olaf Bergmann to improve
the situation here. He is willing to take some external hints and work
so after tuning the build process it will be easier to package the 
libcoap.

I don't need a sponsor, happily Guido Guenther is willing to upload the 
package after checking my work.

http://coap.technology/
http://www.ietf.org/rfc/rfc7252.txt
http://6lowapp.net/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUr5JGAAoJEIMBYBQlHR2wlWQQAJVL/LoGm2vUQp4V79mMpiLP
o3Dj3/cv73iAn4FWPDOoXdK7ic7OdA3u36nllYdYhMQGak2pNFtxe+foBGDxmISt
3I7cpolX8qmej+zOLb64aZ0XGRwjolXM5ZppID8aXpRHPWm0JPNEovyOqY83T33C
6qRJ3c96TuDN3Xn+k0oYW9uVRI5WwvtQfyUUk6A27gnPUnxaiq2jBJkYOWaS5mvu
AlRExGj/koouB0k+C2VHfq6HYQd3JoS/suxYjWJC/PIRaO7HRiR87iHFxwsI39xl
VsozSUzHw3WE+FcxC8aPmnrfFSMA65UgYtkjmgdv9JokT4r9hL3xB/n28ZS0XeZK
7Plr7yRYg1SzmYnjb2U4lCVkDwfCo32MQ+e5DdDE2dbDl3XOwnZ9RIXU812CzUoV
nz+zdIvGhnwPSa+lahTXDGDENYGuPkhA46qqd3q7kVlRvEgECOo0XYe/0cjsrAnl
C8ZX11RyAc2cvB+1pOFUb7ZOfmWzJI8L4m9UBkPjFL5kmSDoY1K/tJtOv7uycb9I
xhUv8IsIaJusQSVlNyQeXFQ2Daq7JzilKC9L2Q3A2qRlQXtTAgtaLp5Rqrnoe9iQ
XiQDa2iPpDUOR0j38oaT8wVpbzpgACPpPUIu2oDek3ugGRTWTfpaa5ZoweZ5qZPA
tlH+sxDm9fNoyU3+o2Fp
=cGu7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150109083310.18537.12719.report...@x201s.cruise.homelinux.net



Bug#774928: ITP: libcoap -- library for the CoAP protocol written in C

2015-02-12 Thread Carsten Schoenert
On Fri, Jan 09, 2015 at 09:33:10AM +0100, Carsten Schoenert wrote:
> Currently the upstream source is lacking some minor tweaks like
> versioning of the library and also symbol versioning. The build
> environment is improvable. I'm in contact with Olaf Bergmann to improve
> the situation here.

The current state on the rework of the build environment can be found on
my Github page within a local copy of the upstream tree in the branch
'4upstream'.

  https://github.com/tijuca/libcoap/tree/4upstream

But note, I'm offen rebasing this branch because I work from various PCs
on the projects and using the Github service to interchange my work! 

If you have some critisim and/or you are willing to help please contact me!

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150212080703.ga22...@x201s.cruise.homelinux.net



Bug#811169: ITP: colorfultabs -- Color tabs differently and make them easy to distinguish

2016-01-16 Thread Carsten Schoenert
Hello Ximin,

Am 16.01.2016 um 12:14 schrieb Ximin Luo:
> Package: wnpp
> Severity: wishlist
> Owner: Ximin Luo 
> 
> * Package name: colorfucolorfultabsltabs

any special reason for not naming the package 'xul-ext-colorfultabs'?
There seems to be a consensus to prefix the AddOns for Iceweasel and
Icedove with xul-ext-*. By this you can easily do packaging by the help
of mozilla-devscripts.

Please see:
https://wiki.debian.org/Mozilla/ExtensionsPolicy

-- 
Regards
Carsten Schoenert



Bug#811169: ITP: colorfultabs -- Color tabs differently and make them easy to distinguish

2016-01-16 Thread Carsten Schoenert
[Now to the right list in CC]

Hello Ximin,

Am 16.01.2016 um 12:14 schrieb Ximin Luo:
> Package: wnpp
> Severity: wishlist
> Owner: Ximin Luo 
> 
> * Package name: colorfucolorfultabsltabs

any special reason for not naming the package 'xul-ext-colorfultabs'?
There seems to be a consensus to prefix the AddOns for Iceweasel and
Icedove with xul-ext-*. By this you can easily do packaging by the help
of mozilla-devscripts.

Please see:
https://wiki.debian.org/Mozilla/ExtensionsPolicy

-- 
Regards
Carsten Schoenert



Bug#811169: ITP: colorfultabs -- Color tabs differently and make them easy to distinguish

2016-01-16 Thread Carsten Schoenert
Hello Ximin,

Am 16.01.2016 um 12:33 schrieb Ximin Luo:
> Hi Carsten, the name "colorfultabs" above refers to the source
> package name, which conforms to what the policy you linked states:

a yes, you are right. I was focused on the binary package name. Then
everything is fine.

-- 
Regards
Carsten Schoenert



Bug#692984: ITP: sogo-connector -- full DAV client for Thunderbird/IceDove

2013-08-21 Thread Carsten Schoenert
Hello Joseph,

On Sun, Nov 11, 2012 at 12:41:14PM -0500, Joseph Nahmias wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joseph Nahmias 
> 
> * Package name: sogo-connector
>   Version : 10.0.3
>   Upstream Author : Inverse, Inc
> * URL : http://sogo.nu/
> * License : GPL2
>   Programming Lang: XUL/Javascriopt
>   Description : full DAV client for Thunderbird/IceDove
> 
>  This extension enables Thunderbird/IceDove as a full DAV client for use
>  with groupware servers (such as SOGo).  Features include:
>  .
>   * Event organizers
>   * CardDAV support that is generic, so you can use it with any
> address book service (eg. fruux)
>   * Support for WebDAV access control lists (ACL)

what about your ITP for the sogo-connector?
I worked locally with the packaging for this plugin and would like to do
the packaging for Debian because the have since a few weeks a user wish
for for the sogo-connector addon (see #705488).
I have talked to Jeroen about some possible problems with the
sogo-connector. He can provide me/us a personal login to the sogo
instance on the servers on inversa.ca for a better testing of the
package.

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130821110313.ga4...@x201s.cruise.homelinux.net



Bug#692984: upstream binary / DAViCal / CardDAV problems on wheezy

2013-08-29 Thread Carsten Schoenert
Hello Daniel,

On Thu, Aug 29, 2013 at 03:00:58PM +0200, Daniel Pocock wrote:
> Is icedove 17 likely to appear in backports any time soon?  I might try
> building it on wheezy and run it with the SOGo connector 17 plugin to
> see if it is more successful

I don't think we will spend much time on getting ID17 in
wheezy-backports. Christoph has uploaded Icedove 17.0.8-1 yesterday to
stable-security. So shortly the latest version of Thunderbird will be
landing in Wheezy thrue stable-security.
The differences between stable-security and sid are quite marginal. We
have to work more on the current build problems for soem platforms.

Localy I have the sogo-connector packaged for Icedove 17, but until now
I don't have it installed yet. For testing surpose I use the 10.0.12 in
on my laptopt with testing.
Right now I'm sitting in front of a Wheezy installation with a Icedove
17 from stable security. Maybe later I can install the sogo-connector
here, right now I'm trying to get the next ESR release of Thunderbird
(until now just 24.0b1) packaged.

If there are no greater problems with my sogo-connector package I can
provide you a download.

Regrads
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130829133749.ga27...@x201s.cruise.homelinux.net



Bug#783603: ITP: libvmime -- C++ class library for working with RFC-822 and MIME messages

2015-04-28 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: libvmime
  Version : 0.9.1
  Upstream Author : Vincent RICHARD 
* URL : http://www.vmime.org
* License : GPL v3
  Programming Lang: C++
  Description : C++ class library for working with RFC-822 and MIME messages

 VMime is a powerful C++ class library for working with RFC-822
 and MIME messages and Internet messaging services like IMAP, POP
 or SMTP.
 .
 With VMime you can parse, generate and modify messages, and also
 connect to store and transport services to receive or send messages
 over the Internet. The library offers all the features to build a
 complete mail client.
 .
 Main Features Overview
 * RFC-2822 and multipart messages
 * aggregate documents and embedded objects
 * 8-bit MIME and encoded word extensions
 * full support for attachments
 * POP3, IMAP, SMTP, maildir and sendmail
 * SSL/TLS security layer and X.509 certificates (using either GNU TLS or
   OpenSSL)
 * SASL authentication (using GNU SASL)
 * Internationalized Email Support (RFC-6532)

libvmime is a build dependencie for the Zarafa packages and was removed
from the repository with a request for removal on bug #774306 some times
ago.
The pakage will be maintained by the pkg-giraffe maintainers.
https://alioth.debian.org/projects/pkg-giraffe/

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150428101453.28364.30749.report...@lenovo.as-it.org



Bug#783640: ITP: zarafa-webaccess -- Next generation web interface for Zarafa

2015-04-28 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: zarafa-webaccess
  Version : 2.0.2
  Upstream Author : Zarafa BV, Delft, NL
* URL : http://www.zarafa.com/
* License : AGPL3
  Programming Lang: PHP, JS, CSS
  Description : Next generation web interface for Zarafa Collaborations 
Platform

 zarafa-webapp provides various plugins for the main zarafa-server
 application. The plugins are written in PHP with usage of CSS, JSON and
 Ext JS for usage in modern web browser for the use of the Zarafa
 Collaboration Platform.

This package is recommended packae for the zarafa-server packages which
will get some drive after changes to the license by Zarafa. See ITP #658433
for more infos on the zarafa-server packages.

The package will be maintained by the pkg-giraffe maintainers.
https://alioth.debian.org/projects/pkg-giraffe/

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150428164429.4942.23014.report...@jessie.cruise.homelinux.net



Bug#774928: ITP: libcoap -- library for the CoAP protocol written in C

2015-06-21 Thread Carsten Schoenert
Hello,

after a few addition to upstream I have started a first repository for
packaging.

 https://github.com/tijuca/libcoap-packaging

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150621161211.ga7...@jessie.cruise.homelinux.net



Bug#703226: ITP: patchwork -- a console or web based patch tracking system

2013-03-17 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: patchwork
  Version : actual like 0.0.0-[git-SH1-ID]
  Upstream Author : Jeremy Kerr j...@ozlabs.org
* URL : http://jk.ozlabs.org/projects/patchwork/
* License : GPL2
  Programming Lang: Python, Shell, Django Framwork with jquery
  Description : a console or web based patch tracking system

Patchwork is designed to facilitate the contribution and management of
contributions to an open-source project with a patch tracking system.
In case of high activity on a mailinglist patches are offen neglected
because of the amount of new or reworked patches every day.
Patchwork helps to keep the overview to all of them because every mail
with a patch gets into a database. The collected patches are then visible
in a WebGUI on the server there the patchwork software is running.
Inside the WebGUI it is possible for registered people to mark every
single patch like 'accepted', 'under review', 'rejected' and so on.
It's also possible to assign patches to single persons.

Patchwork includes a python script 'pwclient' that allows the user to 
control the patches from a remote client.

Patchwork is not related to a specifiv VCS.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130317094056.ga6...@x201s.cruise.homelinux.net



Bug#703226: ITP: patchwork -- a console or web based patch tracking system

2013-05-11 Thread Carsten Schoenert
Hello,

the current work can be found on https://github.com/tijuca/patchwork

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130511225801.ga15...@wheezy.criuse.homelinux.net



Bug#692984: Expected upload of sogo-connector

2014-04-30 Thread Carsten Schoenert
Hello Boris,

Am 30.04.2014 12:41, schrieb Boris Barbour:
> I'm interested in obtaining the sogo-connector, as this seems to be the 
> only way to sync contacts with owncloud. I'd prefer to get it through 
> the debian repositories. The messages above suggest that it could be (or 
> has been) uploaded, which is good news. When might we expect it to appear?

thanks for your interests!
I don't know then the FTP Team will allow the upload of the package, so
sorry, I can't say something promising right now.

You can rebuild the package by yourself using the current repository
which will be found on

  https://github.com/tijuca/sogo-connector

You will probably need a sid chroot to build the package, right know I
always used git-pbuilder and doesn't have cared about backports or so.
But that should not be a big problem to created a wheezy-backport
package too.

-- 
Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5360e292.5010...@t-online.de



Bug#703226: ITP patchwork

2014-07-06 Thread Carsten Schoenert
Hello Arturro,

On Fri, Jul 04, 2014 at 02:40:50PM +0200, Arturo Borrero Gonzalez wrote:
> Hi there!
> 
> Are you still interested in this ITP?

basicly yes, but unvortunately over the last months I havn't had much time
for working on the packaging. So if you want to take over the ITP than
feel free to do it so.
I think I have some local work left laying here ... but I don't know if it
would be useful.

I'd like to see patchwork in Debian, there are some mailinglists
(especially on Alioth) there patchwork could be really helpful.

If you need some more infos please let me know.

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140706074243.ga3...@x201s.cruise.homelinux.net



Bug#692984: Expected upload of sogo-connector

2014-07-22 Thread Carsten Schoenert
Hello Luca,

Am 22.07.2014 13:59, schrieb Luca Capello:
> Any reason why this is not on Alioth?

there is no special reason, I just started last year the packaging and
wanted the repo putting in some "official" place to let other see the
current state. But I wanted be able to rebase and push my work without
any take care for on person depended on a repository in a more public
place like Alioth.

Once the package is accepted it will move to Alioth.

> Actually, using a *plain* wheezy chroot is not enough:
...
> Here is the reason:
> =
> $ rmadison icedove-dev | grep wheezy
>  icedove-dev | 10.0.12-1  | wheezy| amd64, armel, armhf, 
> i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, 
> s390x, sparc
>  icedove-dev | 17.0.10-1~deb7u1   | wheezy-security   | ia64, kfreebsd-amd64, 
> kfreebsd-i386, mips, mipsel
>  icedove-dev | 24.5.0-1~deb7u1| wheezy-security   | s390, sparc
>  icedove-dev | 24.6.0-1~deb7u1| wheezy-security   | amd64, armel, armhf, 
> i386, powerpc, s390x
> $ 
> =
> 
> I confirm that adding the wheezy-security repository is enought to build
> a wheezy-backports without changing anything in the current Debian
> sources on GitHub.

I know this circumstance, but thanks for hinting.

> Since we currently use this extension, I am interested in a
> wheezy-backports and I could maintain it by myself, but only once it
> reaches testing and anyway not before the next 3 months.

A backport is heavily depending on entering the testing release, so I
still don't care much about it in the current state. But as you wrote
it's more a question of the chroot to build a backport package. Right
know I would be happy to get the connector into testing before the freeze.

-- 
Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ceb08c.4060...@t-online.de



Bug#888104: ITP: kicad-symbols -- schematic symbols for KiCad's eeschema

2018-01-23 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: kicad-symbols
  Version : 5.x.x+$date
  Upstream Author : KiCad Community
* URL : https://kicad.github.io/symbols/
* License : CC-BY-SA 4.0 with exception*
  Programming Lang: Plain text
  Description : schematic symbols for KiCad's Eeschema editor

Eeschema is a powerful schematic capture software distributed as part of
KiCad. A schematic design with Eeschema is heavily based on the
availability of schematic symbols which needed to be used for creating of
own schematics.
Due the flexibility of Eeschema and the nature of community driven
development of schematics for KiCad with a fast evolution of symbols for
Eeschema it's difficult to keep track of the new and updated symbols
with the more static releases of KiCad itself (currently the schematic
symbols are available by kicad-common). Thus it makes sense to keep the
packaging of symbols for Eeschema in a own source package as this makes
it easier to provide updated packages not only for unstable/testing.

kicad-symbols will be a part of the transition of the existing
kicad-common package into own pieces.

The package will be maintained in the pkg-electronics-team together with
Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu).
We will try to keep the package the same in Debian and Ubuntu. More Co
maintainers are welcome!

*License exception
"To the extent that the creation of electronic designs that use 'Licensed
Material' can be considered to be 'Adapted Material', then the copyright
holder waives article 3 of the license with respect to these designs and
any generated files which use data provided as part of the 'Licensed
Material'."

more license information http://kicad-pcb.org/libraries/license/



Bug#888108: ITP: kicad-footprints -- footprint libraries for KiCad's Pcbnew editor

2018-01-23 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: kicad-footprints
  Version : 5.x.x+$date
  Upstream Author : KiCad Community
* URL : https://kicad.github.io/footprints/
* License : CC-BY-SA 4.0 with exception*
  Programming Lang: Plain Text
  Description : footprint libraries for KiCad's Pcbnew editor

Pcbnew is a powerful printed circuit board software and part of the
KiCad suite.
Pcbnew manages libraries of footprints. Each footprint is a drawing of
the physical component including its land pattern (the layout of pads on
the circuit board). Footprints have a strong relationship to the
schematic symbols that are used in Eeschema and both parts
(kicad-symbols and kicad-footprints) depending on each other in some
way.
Like for the schematic symbols the footprints are also evolving and
growing fast and this brings in some difficulty to provide actual footprint
data for KiCad within Debian and like planned for the schematic symbols
the footprints need to go also into a own source package.
This is another part of transitioning the existing kicad-common package
into dedicated smaller packages.

The package will be maintained in the pkg-electronics-team together with
Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu).
We will try to keep the package the same in Debian and Ubuntu. More Co
maintainers are welcome!

*License exception
"To the extent that the creation of electronic designs that use 'Licensed
Material' can be considered to be 'Adapted Material', then the copyright
holder waives article 3 of the license with respect to these designs and
any generated files which use data provided as part of the 'Licensed
Material'."

more license information http://kicad-pcb.org/libraries/license/



Bug#888116: ITP: kicad-packages3d -- 3d model libraries for KiCad's Pcbnew editor

2018-01-23 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: kicad-packages3d
  Version : 5.x.x+$date
  Upstream Author : KiCad Community
* URL : https://kicad.github.io/packages3d/
* License : CC-BY-SA 4.0 with exception*
  Programming Lang: Plain Text
  Description : 3d model libraries for KiCad's Pcbnew editor

Pcbnew is a powerful printed circuit board software and part of the
KiCad suite.
The 3d models are intended to be rendered by the Pcbnew 3d viewer or
other MCAD software. These 3d models are completely optional and not
really needed for developing any PCB layout but they give a great
possibility to see how your PCB would look like.

A downside of the 3d models are the size of each model. That's one of
the reasons for this ITP, the current available 3d models are that big
to be packaged in the existing kicad-common package and a own source
package is easier to handle in the long term.

The package will be maintained in the pkg-electronics-team together with
Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu).
We will try to keep the package the same in Debian and Ubuntu. More Co
maintainers are welcome!

*License exception
"To the extent that the creation of electronic designs that use 'Licensed
Material' can be considered to be 'Adapted Material', then the copyright
holder waives article 3 of the license with respect to these designs and
any generated files which use data provided as part of the 'Licensed
Material'."

more license information http://kicad-pcb.org/libraries/license/



Bug#888476: ITP: kicad-templates -- read to use project templates for KiCad

2018-01-25 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: kicad-templates
  Version : 5.x.x+$date
  Upstream Author : KiCad Community
* URL : https://github.com/KiCad/kicad-templates
* License : CC-BY-SA 4.0 with exception*
  Programming Lang: Plain text
  Description : read to use project templates for KiCad

KiCad is a cross platform and Open Source EDA (Electronics Design Automation)
suite which can be used for the creation of electronic schematic diagrams and
PCB artwork. The flexibility is mainly based on libraries for schematic symbols,
footprints and 3D models. But it also offers a template mechanism which makes it
easy for user to base their work on prepared projects which can include
prearranged schematic and or basic PCB layouts.
Really common examples for such templates are well prepared PCB layouts for the
Arduino boards but also for Raspberry PI or BeagleBone.

Such templates are currently installed by kicad-common. Due the regular updates
to the kicad-templates library it's difficult to follow that dynamic development
with the more contrary static preparation of point releases of KiCad without
(the mostly unneeded) completely rebuild of the existing src:kicad package.
Like done for the schematic symbols, footprints and 3d-packages this ITP is to
move out the templates into a own source package and make package maintenance
easier. For the users this brings more frequent updates of the KiCad community
templates.

The package will be maintained in the pkg-electronics-team together with
Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu).
We will try to keep the package the same in Debian and Ubuntu. More Co
maintainers are welcome!

*License exception
"To the extent that the creation of electronic designs that use 'Licensed
Material' can be considered to be 'Adapted Material', then the copyright
holder waives article 3 of the license with respect to these designs and
any generated files which use data provided as part of the 'Licensed
Material'."

more license information http://kicad-pcb.org/libraries/license/



Bug#888489: ITP: ngspice-dfsg -- Spice circuit simulator - DFSG compatible parts

2018-01-26 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: ngspice-dfsg
  Version : 27
  Upstream Author : various (mainly Holger Vogt, Paolo Nenzi, Robert
Larice)
* URL : http://ngspice.sourceforge.net/
* License : BSD-3-clause, LGPL-2(+), GPL-2(+)
  Programming Lang: C, TclTk, plain text
  Description : Spice circuit simulator - DFSG compatible parts

Packages for NGspice are available due license incompatibilities in old
versions to the DFSG only in non-free.
With version 27 (released in September 2017) most of the used non DFSG
compatible licensed files/folders have been moved over to BSD 3-clause
(upstream uses here the name 'New BSD') and by this the build-able files
and binary stuff can now be considered as free enough by the DFSG.
There are still parts that uses licenses that aren't compatible with the
DFSG. All those parts can be excluded and the binaries are built without
support of that software parts. NGspice upstream has updated their
online available FAQ [2] about the used licenses, please look at point 1.5.

I prepared a wiki site to collect and track the status for files and
folders in question [3].

My working tree can be found on GitHub [4] for now. I'd really happy if
someone can have a look at this especially for the license issues which
the new version shouldn't have any longer. I had some nice communication
with upstream which gave me some guidance for the needed removal of
still not free enough licensed files and folders, which would bring in
some packages could still only served by non-free. I will probably also
maintain the src:ngspice package later as there are otherwise some
overlapping files between both source packages. I'm in contact to the
current Uploader Gudjon I. Gudjonsson about this.

I will maintain this package in the pkg-electronics-team, co-maintainers are
welcome! It's a build dependency for KiCad 5 which come with schematic
simulation based on the libngspice library which isn't available in the
non-free packages.

[1] https://tracker.debian.org/pkg/ngspice
[2] http://ngspice.sourceforge.net/faq.html
[3] https://wiki.debian.org/KiCad/ngspice
[4] https://github.com/tijuca/ngspice-dfsg



Bug#888489: ITP: ngspice-dfsg -- Spice circuit simulator - DFSG compatible parts

2018-01-31 Thread Carsten Schoenert
Hello Andreas,

On Wed, Jan 31, 2018 at 11:53:24AM +0100, Andreas Tille wrote:
> Hi Carsten,
> 
> maintaining this package in pkg-electronics-team is fine.  I know less
> about this team and its connection to Debian Science but please
> coordinate with current ngspice maintainer who maintains the related
> packages in Debian Science Git (at salsa.d.o).

yes, the current plans for ngspice-dfsg are an outcome of my various
conversations with Gudjon (CC'd) who has obviously done the maintenance
of src:ngspice. We also talked about the needed maintenance of the
current ngspice packages in non-free after the introducing of
ngspice-dfsg. I will take care on this in the long term but I'm happy
for any help on this as I'm not very experienced with TclTK e.g.

The libngspice library is a optional dependency for KiCad, but no hard
requirement. So uploading ngspice-dfsg isn't a very high priority on my
side. I will need to prepare the needed changes for ngspice in non-free
before finally uploading the dfsg variant. This will all happen within
the experimental release.

Regards
Carsten



Bug#703226: can I reuse the name patchwork for another ITP ?

2018-04-12 Thread Carsten Schoenert
Hello Paolo,

On Wed, Apr 11, 2018 at 06:33:44PM +0200, Paolo Greppi wrote:
> Hi,
> 
> I was wondering whether the RFP for patchwork (a console or web based
> patch tracking system) can be closed.

no, even if no one is working an packaging the sense of such open
reports is simply to show that there are some people that had an
interest in the past to package this software. And this is mostly
helpful for people who possible want to step in or need to find other
packages which might conflict with their packages or package name, like
here in your case.
Normaly RFPs are moving to an ITP and closed by a later upload.

> The bug has seen no activity for 2.5 years.
> 
> The interest of this for Debian is probably lower now than it was 5
> years ago, as now we have salsa, which has merge requests (similar to
> github's pull requests).

The intention of patchwork is completely different to Salsa, GitHub,
GitLab and similar.
Patchwork a kind of standard in the development of the kernel sub
modules and a lot ob big IT company using this in their development like
IBM and Intel. So I don't see in detail a dedicated interest for the
Debian project itself and we package software mostly for users. I don't
know of any teams or maintainers which might use patchwork in their
workflow, but I wouldn't be surprised if this is already happen.

> Merge requests are easier to use than command-line patches and should
> lower the barrier for contributors (that was one of the reason for the
> switch from alioth cgit to salsa).

That's for sure true, but there are also downsides. Reviewing changes
isn't always easier (at least in my eyes) and need always a network
connection. 

> Besides the future of alioth mailing lists is uncertain ATM:
> https://wiki.debian.org/Alioth#Mailing_lists
> 
> I am asking because I was planning to use the name patchwork for
> something else:
> https://github.com/ssbc/patchwork

Given the age that patchwork now has (initial commit 2008 vs 2015 for
ssbc-patchwork) and the completely different use cases I personally
would hereby suggesting to choose a different source and binary name for
the patchwork software for Secure Scuttlebutt.

Why not use ssb-patchwork or ssbc-patchwork as name? I'd prefer the
former name.

Regards
Carsten



Bug#783640: retitle 783640 to zarafa-webapp -- Next generation web interface for Zarafa

2016-02-10 Thread Carsten Schoenert
A small update ...

The Zarafa ZCP suite is waiting in the new queue, zarafa-webapp has a
depency on this package. The packaging is almost ready but is awaiting
the Zarafa ZCP (#658433).

Regards
Carsten



Bug#844643: ITP: flatcam -- 2D Computer-Aided PCB Manufacturing on a CNC router

2016-11-17 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: flatcam
  Version : 8.5
  Upstream Author : Juan Pablo Caram 
* URL : http://flatcam.org/
* License : MIT
  Programming Lang: Python
  Description : 2D Computer-Aided PCB Manufacturing on a CNC router

FlatCAM is a program for preparing CNC jobs for creating prototyps of  PCBs on
a CNC router.  You can open Gerber, Excellon or G-code, edit it or create from
scratch, and output G-Code. Isolation routing is one of many tasks that FlatCAM
is perfect for.

There seems to be no other packaged software for PCB milling in Debian, as this
peace of software is rather small and not complex I think it's useful, at least
for me.
I'd like to place this package into the pkg-electronics team as other PCB
related package are workend on there. I will need a sponsor.

Regards
Carsten



Bug#844643: ITP: flatcam -- 2D Computer-Aided PCB Manufacturing on a CNC router

2016-11-20 Thread Carsten Schoenert
Hello pkg-electronics members,

Simon was answering on my ITP from several days ago for FlatCAM and was
offering a probably sponsoring for the package (Thanks Simon!).
As I like to place the package into the pkg-electronics ecosystem as it
fits best here I believe, I would like to ask if the pkg-electronics
team member agree that I can set the maintainer ship to pkg-electronics
and if some of you would kindly sponsor the FlatCAM package at some point?

I'm working on other packages as a DM for quite some time so I have some
packaging experience for about 5-6 years as I'm co-maintaining Icedove
package for this time with Christoph and Guido. A few months ago I was
starting to bring the kicad package into a git-buildpackage workflow
which reflected in a upload of a new prepared version by Georges some
days ago.

I'd be happy if the pkg-electronics team would take a look into my work
of packaging  and hopefully later could sponsor a FlatCAM upload. I
prepare the packaging currently on my GitHub site [1].

On 20.11.2016 00:04, Simon Richter wrote:
> Hi,
> 
> On 17.11.2016 19:33, Carsten Schoenert wrote:
> 
>> * Package name: flatcam
> 
>> I'd like to place this package into the pkg-electronics team as other PCB
>> related package are workend on there. I will need a sponsor.
> 
> In case there are no other sponsors, I could do it, but please treat
> this as a last resort as I often have long stretches where I don't even
> find time to go online.
> 
>Simon
> 
> 

[1] https://github.com/tijuca/flatcam

-- 
Regards
Carsten Schoenert



signature.asc
Description: OpenPGP digital signature


Bug#881475: RFP: emojione-colr -- EmojiOne font in COLR/CPAL layered format

2017-11-12 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist

* Package name: emojione-colr
  Version : 0.2.2
  Upstream Author : Timothy Guan-tin Chien < timdr...@gmail.com >
* URL : https://github.com/mozilla/emojione-colr
* License : ASL-2.0 and CC-BY-4.0
  Programming Lang: JS, Python, Makefile
  Description : EmojiOne font in COLR/CPAL layered format

 Create a COLR/CPAL-based color OpenType font from the EmojiOne
 collection of emoji images.
 Useful font on systems that support layered color TrueType fonts, e.g.
 Mozilla Firefox and other Gecko-based applications running on any
 platform.

Currently Firefox and Thunderbird as well ship that font as an embedded
pre-build font and need that to display EmojiOne graphics. For the
typical reasons to avoid shipping of embedded files it would be useful
booth packages could depend on such a font package. And other
applications could use that font too.

See also bugreports #849602 and #881299.



Bug#881424: RFP: ausweisapp2 -- online authentication using German identity document

2017-11-13 Thread Carsten Schoenert
Hello Martin,

it's about two years ago while I was trying to convince Governikus Gmbh
to open the source for that application. This conversion was not really
user friendly and I gave up on that quickly.
But well, it seems in between the German government has changed their
mind on that. Definitely a step forward.

Unfortunately there is still a CLA signing needed to forward patches
upstream.

https://cla-assistant.io/Governikus/AusweisApp2

> 2. Grant of Copyright License.
> 3. Grant of Patent License.

I'm unsure if a package maintainer or at least myself will support such
things as I diassagree on both points strictly.

Now that even GitLab has take back their CLA requirement for good
reasons it would be straight forward to be clear on that here too. Maybe
it's worth talk to the FSFE due their Public Code campaign
https://publiccode.eu/

Regards
Carsten



Bug#865521: lintian: check for embedded-pear-module needs to be more granular for unstable/testing/stretch

2017-12-19 Thread Carsten Schoenert
Hello Chris,

Am 19.12.2017 um 18:49 schrieb Chris Lamb:
...
>> I don't know if there is a aquivalent package available after the PHP7
>> transition.
> 
> I'm not in the PHP ecosystem, alas.

me too. :-/

> Can someone who does let us know the modern equivalent?
There was a ITP started in the summer this year to re-introduce a
updated php-mail-mimedecode package. But I guess Prachi Srivastava
 is needing a sponsor anyway.
If we can get a up2date package the lintian check would become valid for
buster and unstable again.

But for the Z-Push package upstream has made some modifications to the
copied usptream files and we had to set a lintian override anyway.

@Prachi
Do you need any help? What's the current state of your ITP? Do you need
a sponsor?

https://bugs.debian.org/865521

-- 
Regards
Carsten Schoenert



Bug#783640: retitle 783640 to zarafa-webapp -- Next generation web interface for Zarafa

2016-07-02 Thread Carsten Schoenert
Control: retitle 783640 kopano-webapp -- Next generation web interface for 
Kopano

One more update, the Zarafa company is renaming the Zarafa Communication
Platform (ZCP) to Kopano.
Related to this the webapp will called kopano-webapp instead.

Regards
Carsten

On Wed, Feb 10, 2016 at 10:14:57PM +0100, Carsten Schoenert wrote:
> A small update ...
> 
> The Zarafa ZCP suite is waiting in the new queue, zarafa-webapp has a
> depency on this package. The packaging is almost ready but is awaiting
> the Zarafa ZCP (#658433).
> 
> Regards
> Carsten



Bug#658433: RFP: zarafa -- complete groupware, email and collaboration suite

2016-07-02 Thread Carsten Schoenert
Control: retitle 658433 kopano -- complete groupware, email and collaboration 
suite

On Wed, Jan 07, 2015 at 08:44:32AM +0100, Guido Günther wrote:
> On Thu, May 10, 2012 at 02:34:44PM +0200, W. Martin Borgert wrote:
> > owner 658433 pkg-giraffe-maintain...@lists.alioth.debian.org
> > thanks
> > 
> > See http://wiki.debian.org/Giraffe and
> > https://alioth.debian.org/projects/pkg-giraffe/
> > for the ongoing packaging effort.
> 
> The current Debian wiki URL is
> 
> https://wiki.debian.org/Groupware/Giraffe
> 
> Note that Zarafa also changed the trademark policy:
> 
> http://www.zarafa.com/content/zarafa-trademark-policy
> 
> which will make a rebranding superfluous and ease packaging a
> lot. Discussions are taking place on
> 
> https://lists.alioth.debian.org/mailman/listinfo/pkg-giraffe-discuss

Zarafa decided to do based on the changed trademark also do renaming the
suite to Kopano because some source code parts needs to be rewritten due
license issues. To finalize those changes the suite is now named Kopano
and has no "Enterprise Options" like extra license for spedific parts of
the software.

The new Website for Kopano is found on

  https://kopano.com/

The current source code can be found on

  https://stash.kopano.io/projects/KC/repos/kopanocore/browse

and the tarballs on

  https://download.kopano.io/community/core:/sourcecode/

The packageing will happen with the information Guido pointed out earlier.

Regards
Carsten



Bug#844643: ITP: flatcam -- 2D Computer-Aided PCB Manufacturing on a CNC router

2017-09-27 Thread Carsten Schoenert
Hi,

I'm still interested to do the packaging of flatcam.

Flatcam is while writing still depending on Qt4 in most or all of the
parts, due the announcement of Qt4 removal within the Buster release
preparation I contacted upstream and informed Juan Pablo about the
planned Qt4 removal.
Unfortunately I have got no feedback on this.

I plan not to do further packaging until upstream has made some
statement about further development of flatcam depending on the
deprecated state of Qt4.

https://bitbucket.org/jpcgt/flatcam/issues/221/intent-to-package-flatcam-for-debian

In case someone can help usptream to swich to a Qt5 based flatcam please
feel free to do so.

Regards
Carsten

On Thu, Nov 17, 2016 at 07:33:28PM +0100, Carsten Schoenert wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Carsten Schoenert 
> 
> * Package name: flatcam
>   Version : 8.5
>   Upstream Author : Juan Pablo Caram 
> * URL : http://flatcam.org/
> * License : MIT
>   Programming Lang: Python
>   Description : 2D Computer-Aided PCB Manufacturing on a CNC router
> 
> FlatCAM is a program for preparing CNC jobs for creating prototyps of  PCBs on
> a CNC router.  You can open Gerber, Excellon or G-code, edit it or create from
> scratch, and output G-Code. Isolation routing is one of many tasks that 
> FlatCAM
> is perfect for.
> 
> There seems to be no other packaged software for PCB milling in Debian, as 
> this
> peace of software is rather small and not complex I think it's useful, at 
> least
> for me.
> I'd like to place this package into the pkg-electronics team as other PCB
> related package are workend on there. I will need a sponsor.
> 
> Regards
> Carsten



Bug#877480: ITP: kopano-webapp-plugin-files -- Kopano WebApp files plugin

2017-10-01 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: kopano-webapp-plugin-files
  Version : 2.1.0-beta1
  Upstream Author : Kopano 
* URL : https://kopano.com/
https://stash.kopano.io/projects/KWA/repos/files/browse
* License : AGPL-3, BSD-3, Expat, LGPL-3
  Programming Lang: PHP, JS
  Description : Kopano WebApp files plugin

 This package is a plugin for kopano-webapp, a web interface for the Kopano
 Collaboration Platform.
 .
 File management integration plugin for the kopano-webapp, allows a user to
 browse, save and attach files from a file share backend. Supported backends
 are FTP and WebDav (for example Owncloud or NextCloud).

This package is a additional plugin for kopano-webapp which is currently
waiting for review in NEW.
It will be maintained by Giraffe Maintainers 


Regards
Carsten



  1   2   >