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

[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#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

[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#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

[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

[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#1065749: ITP: flask-debugtoolbar -- Debugging toolbar overlay information for Flask applications

[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#1057386: ITP: imsprog -- linux chip programmer for CH341a devices

[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#1057386: Subject: ITP: imsprog -- linux chip programmer for CH341a devices

[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: Upload of imsprog

[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: [Pkg-electronics-devel] imsprog , #1057386

[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#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

[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#1062655: O: libcoap3 -- C-Implementation of CoAP - libraries API version 3

[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#1058036: ITP: blanket -- Listen to different sounds

[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!? :-)


--
Regards
Carsten

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

[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#1051978: ITP: python-yamlfix -- Simple opionated yaml formatter that keeps your comments

[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#1051758: ITP: python-ruyaml -- YAML 1.2 loader/dumper package for Python

[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#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

[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#1038812: Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[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#1037085: RFP: strawberry-graphql -- GraphQL library for Python that leverages type annotations

[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#1037009: ITP: python-drf-spectacular-sidecar-nonfree -- Serve builds of Swagger UI and Redoc for Django REST framework

[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#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

[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#1028365: ITP: python-covdefaults -- coverage plugin to provide sensible default settings

[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#1028188: ITP: python-validate-pyproject -- Automated checks on pyproject.toml by JSON Schema definitions

[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#1026261: ITP: markdown-exec -- Utilities to execute code blocks in Markdown files

[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#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

[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#1023892: ITP: markdown-callouts -- Python-Markdown extension adding a new block-level syntax

[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#1023891: ITP: mkdocs-literate-nav -- MkDocs extension to specify the navigation in Markdown

[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#1022207: ITP: pysocks -- Lets you send traffic through SOCKS proxy servers

[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#1022155: ITP: mkdocs-click -- MkDocs extension to generate documentation for Click command line applications

[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#1020611: ITP: python-trio-websocket -- Server and client Python library of the WebSocket protocol

[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#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

[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#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

[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

[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#1013194: ITP: django-rich -- Extensions for using Rich with Django

[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#1011194: ITP: mkdocstrings-python-handlers -- Python handler for mkdocstrings

[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#1011192: ITP: python-griffe -- Signatures for entire Python programs

[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#1010382: ITP: mkdocstrings-python-legacy -- Legacy Python handler for mkdocstrings

[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#1009892: ITP: mkdocstrings -- Automatic Python documentation from sources for MkDocs

[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#1009255: ITP: mkdocs-autorefs -- Plugin for MkDocs to automatically link across pages

[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#1009221: ITP: pytkdocs -- Legacy Python handler for mkdocstrings

[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#1008086: ITP: python-lunr -- Python implementation of Lunr.js

[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#1006483: ITP: python3-mergedeep -- A deep merge function for Python

[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#1006480: ITP: mkdocs-redirects -- Plugin for mkdocs to create page redirects

[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#1006479: ITP: mergedeep -- Deep merge function for Python

[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#1006163: ITP: pyyaml-env-tag -- Custom YAML tag for referencing environment variables

[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#1004681: ITP: wcag-contrast-ratio -- Library computing contrast ratios required by WCAG 2.0

[Carsten Schoenert]

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

* Package name: wcag-contrast-ratio
  Version : 0.9
  Upstream Author : Geoffrey Sneddon 
* URL : https://github.com/gsnedders/wcag-contrast-ratio
* License : MIT
  Programming Lang: Python
  Description : Library computing contrast ratios required by WCAG 2.0

 This package provides a Python library that calculates the contrast ratio of
 colors based on the Web Content Accessibility Guidelines (WCAG) 2 standard,
 published by the Web Accessibility Initiative (WAI). The actual WCAG technical
 documents are created by the Accessibility Guidelines Working Group (AG WG),
 which are part of the WAI.
 .
 This library also provides some checking if contrast meets the required level.

This packge is a new build dependency for recent versions of pygments.

It will be maintained within the Python Team.

Bug#1002695: ITP: python-markdown-include -- Extension to Python-Markdown

[Carsten Schoenert]

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

* Package name: python-markdown-include
  Version : 0.6.0
  Upstream Author : Chris MacMackin 
* URL : https://github.com/cmacmackin/markdown-include
* License : GPL-3
  Programming Lang: Python
  Description : Extension to Python-Markdown

 This package is an extension for python3-markdown and provides an
 "include" function, similar to that found in LaTeX (and also the C
 pre-processor and Fortran).

This package is another indirect dependency for NetBox.

I plan to maintain this package within the DPT.

Bug#1002633: ITP: mkdocs-material-extensions -- Markdown extension resources for MkDocs for Material

[Carsten Schoenert]

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

* Package name: mkdocs-material-extensions
  Version : 1.0.3
  Upstream Author : Isaac Muse 
* URL : https:/github.com/facelessuser/mkdocs-material-extensions
* License : MIT
  Programming Lang: Python
  Description : Markdown extension resources for MkDocs for Material

 MkDocs Material provides numerous icons from Material, FontAwesome, and
 Octicons, but it does so by inlining the SVG icons into the source.
 Currently there is no easy way access these icons and arbitrarily insert
 them into Markdown content. Users must include the icon fonts themselves
 and do it with HTML.
 .
 This module allows you to use PyMdown Extensions' Emoji extension to enable
 easy insertion of MkDocs Material's SVG assets using simple :emoji-syntax:.
 This is done by creating our own emoji index and emoji generator. The
 custom index provides a modified version of the Emoji extensions Twemoji
 index.

This package uses pymdown-extensions to extend the functionality of
mkdoc-material.

Both packages from above are uploaded to NEW while writing this ITP.

https://ftp-master.debian.org/new/pymdown-extensions_9.1-1.html
https://ftp-master.debian.org/new/mkdocs-material_8.1.3-1.html

mkdocs-material is a new dependency for NetBox, pymdown-extensions
and also mkdocs-material-extensions are new indirect dependencies for
MetBox.

I plan to maintain this package within the Debian Python Team.

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

[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#992446: ITP: django-graphiql-debug-toolbar -- Django Debug Toolbar for GraphiQL IDE

[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#991740: Please reject graphql-core and graphql-relay from NEW

[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#991872: ITP: python-graphene -- GraphQL Framework for Python

[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#991812: ITP: django-graphene -- Django integration for Graphene

[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#991775: ITP: graphene -- GraphQL Framework for Python

[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#991740: ITP: graphql-core -- GraphQL implementation for Python

[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#991736: ITP: graphql-relay -- Relay Library for GraphQL Python

[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#991692: ITP: python-promise -- Implementation of Promises in Python

[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#991679: ITP: python-text-unidecode -- most basic Python port of the Text::Unidecode Perl library

[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#990874: ITP: drf-yasg-nonfree -- Yet another Swagger generator

[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#990420: ITP: django-cacheops -- Django app adding automatic or manual queryset caching

[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#990341: ITP: swagger-spec-validator -- Validation of Swagger specifications

[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#990289: ITP: django-pglocks -- Django based context manager for PostgreSQL advisory locks

[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#990085: ITP: django-rq -- Django integration with RQ (Redis Queue)

[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#989811: ITP: python-funcy -- Collection of fancy functional tools focused on practicality

[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#989527: ITP: python-markuppy -- module to generate HTML/XML content

[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#988971: ITP: python-django-crispy-forms-foundation -- django-crispy-forms layout objects for Foundation for sites

[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#987417: ITP: libcoap3 -- C-Implementation of CoAP, API version 3

[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#984937: ITP: flatcam-beta -- PCB CAM software (beta release)

[Carsten Schoenert]

Hello Romain,

Am 10.03.21 um 18:03 schrieb Romain Porte:
> Hi,
> 
> 10/03/2021 17:40, Carsten Schoenert :
>> long long ago I intended to package FlatCAM.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844643
>>
>> I stopped working on this due no response from upstream regarding
>> questions related to Qt5 Python bindings so far I remember.
> 
> The only discussion I was able to find is this one:
> 
> https://bitbucket.org/jpcgt/flatcam/issues/221/intent-to-package-flatcam-for-debian
> 
> It seems that upstream is now correctly using pyqt5, at least in their
> Beta branch.
> 
>> Why do you want to name the package flatcam-beta?
> 
> Because flatcam's master branch itself seems abandonned since 2019 and
> misses a lot of useful features. As long as upstream is not making a
> proper release and is keeping development in the Beta branch, I am only
> interrested in using (and packaging) flatcam-beta and not flatcam itself.

and you assume by yourself that by upstream uses a different branch name
the software is something "-beta"?
I disagree on this assumption. My experience in the past was that a lot
of contributors to FlatCAM were not very experienced with git as a VCS.
There are no feature branches used in the past times and there were no
clear rules how the development will happen.

Using a suffix "beta" in the source name and probably in the binary
package name will hold back some user as they don't want Beta software.
And in my eyes this is no beta software at all, I've used it at the time
I was doing some packaging work on it and it worked out as expected.
Also the website says nothing about a FlatCAM Beta version.

So I suggest to get in contact with upstream and clarify the status of
that software and what branch is the base for future releases.

> See https://bitbucket.org/jpcgt/flatcam/branches/ for the difference
> between the two versions: 2865 commits.
> 
> I do not intent to update everytime a new Beta release is made, but want
> to be able to install Flatcam Beta easily without running into a lot of
> dependencies issues that I am currently facing with upstream's Beta branch.

That's the life of a Debian Maintainer. ;)
There is nothing against the paradigm "Release often, release early." So
I see no problem to package related new package versions. And once the
package is hitting testing it's a nice attitude to also provide updates
for the users of Debian stable by uploading the new version to backports
too.

-- 
Regards
Carsten

Bug#984937: ITP: flatcam-beta -- PCB CAM software (beta release)

[Carsten Schoenert]

Hello Romain,

Am 10.03.21 um 17:26 schrieb Romain Porte:
> Package: wnpp
> Severity: wishlist
> Owner: Romain Porte 
> X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org
> 
> * Package name: flatcam-beta
>   Version : 8.994
>   Upstream Author : Marius Stanciu 
> * URL : http://flatcam.org/
> * License : Expat
>   Programming Lang: Python
>   Description : PCB CAM software (beta release)
> 
> FlatCAM lets you take your designs to a CNC router. You can open Gerber,
> Excellon or G-code, edit it or create from scatch, and output G-Code.
> Isolation routing is one of many tasks that FlatCAM is perfect for. It's
> is open source, written in Python and runs smoothly on most platforms.
> 
> I intent to maintain this package under the umbrella of the Debian
> Python team.

long long ago I intended to package FlatCAM.

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

I stopped working on this due no response from upstream regarding
questions related to Qt5 Python bindings so far I remember.

Why do you want to name the package flatcam-beta?

-- 
Regards
Carsten

Bug#833039: O: libpam-radius-auth -- The PAM RADIUS authentication module

[Carsten Schoenert]

retitle -1 ITA: picking up maintenance of libpam-radius-auth

Christoph Goehre and myself are taking over the maintenace of this
package, we use RADIUS authentication daily on our day job and we have a
strong interrest that this package will stay in Debian. ;)

Regards
Carsten

Bug#977605: ITP: arduino-core-avr -- Arduino Core for AVR microcontroller

[Carsten Schoenert]

Control: clone 977605 -1
Control: reassign -1 arduino
Control: retitle -1 arduino: unable to compile sketch
Control: version -1 2:1.8.13+dfsg1-1~exp2

Hello Leonardo,

Am 14.01.21 um 15:36 schrieb Leonardo Canducci:
> Attached is the error log when compiling anyway (no programmer chosen).

thanks for testing the packages.
I assume you are trying to compile a sketch, still the Blinky example
sketch?. The log looks like there is a mismatch around the used .so
files for compiling, smells like there is a mix of 32bit and 64bit
environment or some relation to LTO vs. no LTO.

My guess is that an other Arduino installation is around which is
getting involved within the environment that is used by the Debian packages.

Can you move/backup the folder $(HOME)/Ardunio and $(HOME)/.arduino and
restart the Arduino IDE and the compilation of your sketch?

If I try to compile an empty sketch (just using the code that is used if
I start the IDE, or also the Blinky sketch) with also no selected
Programmer this works both without issues.

-- 
Regards
Carsten

Bug#977605: ITP: arduino-core-avr -- Arduino Core for AVR microcontroller

[Carsten Schoenert]

Hello Leonardo,

Am 14.01.21 um 11:47 schrieb Leonardo Canducci:
> I'm really glad there's an updated arduino package in experimental. 
> Right now some missing dependencies such as arduino-core-avr prevent
> installing it but I guess somebody is maintaining these new packages or
> there wouldn't be a new arduino package in the first place!
> 
> Anyway I hope it will be installable soon!

I've written some summary about the current state for the  arduino and
it's depending packages to the ML recently. I've prepared the currently
new depending packages and places them on people.d.o. Feel free to test
the current packages please.

https://alioth-lists.debian.net/pipermail/pkg-electronics-devel/2021-January/007639.html

-- 
Regards
Carsten

Bug#976707: O: kopanocore - Complete and feature rich groupware solution

[Carsten Schoenert]

Hello Simon,

I'll add the bug report to the recipients so other can are also see this
mailing.

As you see I'm answering time shifted, it's the time of the year were
more things pop up that needs to be done as usual.

Am 07.12.20 um 12:29 schrieb Simon Eisenmann:
> Hey Carsten,
> 
> thanks for including me in this. I understand why you want to orphan
> kopanocore completely and also agree that it would be the for the
> best. We will also have an internal discussion about this.>
> Generally we improved our release situation a bit with the announce
> of Kopano One and everything related to it but from a Debian point of
> view, the releases are still too frequent and hard too follow.
Frequent releases aren't a real problem. I appreciate them, they show
mostly an active and healthy upstream project.
For Kopano the underlying team in Debian is currently based on only two
persons, Guido and myself, no new contributors came up. In the past Mark
has done a great job to simplify the workload on our side by providing
information, useful tips, intermediary and some kind of glue from Debian
to upstream.

I personally don't use Kopano as it's functionality is to much for me, I
don't need most of the features. I've done all the work just for fun and
because Kopano is the first big alternative for M$ Exchange.

> Our stack has always been complex and i am wondering if it were worth
> the effort for the users to actually have a 100% feature complete
> Kopano in Debian at some point under the assumption (like you stated)
> that our stack is using broadening its use of technologies (Go, Node,
> Rust ..).

Complexity isn't really matter (and shouldn't) in my eyes. We have other
complex packages in the archive which are the wide ground the
distribution is build up. It took up years but today you can run e.g a
GitLab instance only with packages from Debian.

And I don't see a real reason why Kopano could not be part of Debian,
currently the only preventing thing is the man power to drive all the
things. Even if you (Kopano) is using their own repository to provide
packages for their costumers I see a big gain in the maintenance of
required packages of Kopano direct dependencies if Kopano would like to
improve the situation on this.

Kopano isn't the only company that is maintaining some additional
packages on their own to provide the full usability of their own
packages. But in some cases these additional packages are breaking the
update process of the underlying system, or at least bring in some side
effects. This ends that users need to run and administrate machines that
are exclusive for third party software. I see such systems on my day job
and such machines are cost a lot of time and are always some kind of
special.

I also see that Kopano is building their own packages based on more than
the usual C/C++ stuff, so it's not that this work isn't already done.
It's just a small step to do this work upstream (means manage these
packages in Debian) and get the added value quite automatically in all
supported releases and also into Ubuntu. We happily sponsor package
uploads, we've done this for z-push now for over 3 years. Thanks to Roel
who prepared mostly all uploads.

> A fully functional Kopano system would include:
> 
> - Kopano Server and related software (kopanocore, libkcoidc, gsoap +
>   patches, libical + patches, libvmime + patches)
You mentioned here three packages with additional patching, so far I
understand. :)
And gsoap isn't a corner package. That's exactly the situation I mean.
The gsoap maintainer is very responsive and open minded for issues like
that, this was my impression I've made in the past were we had a similar
situation.
libvmime is different, we don't have seen a release (again) for two years.

> - Kopano Web server (kweb)
> - Kopano Web apps (webapp, newer progressive web apps)
> - KDav 
> - Z-Push 
> 
> How do you see this from the Debian perspective - is it even feasible
> or wanted to have a stack like this including all its build
> dependencies (which are probably like 2000 individual things if you
> cound Javascript modules) - what is the Debian position on this?

I think the situation for Debian is relatively simple and driven by the
DFSG. As long software is complaint to these rules there are no reason
why we don't include this software.

The above list isn't much differing from the current package situation.
I only see directly a new library libkcoidc as a new dependency which
need to get packaged.

But yes, quite a lot of time can be spend on unravel PHP and JS
dependencies to not ship big blobs of required additional packages.

> At Kopano we solve this problem by having a build pipeline which has
> a pre-build step which fetches all the dependencies using the
> corresponding system (Go, Node, Rust) and as a second step package it
> which makes it rather easy.

Debian knows that projects tend to do this, but as you also know for
sure the view on this by Debian is that this model isn't 

Bug#977605: ITP: arduino-core-avr -- Arduino Core for AVR microcontroller

[Carsten Schoenert]

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

* Package name: arduino-core-avr
  Version : 1.8.3
  Upstream Author : Arduino 
* URL : https://github.com/arduino/ArduinoCore-avr
* License : BSD-3-clause, Expat, GPL-2+, ISC, LGPL-2.1+
  Programming Lang: Assembler, C, C++, 
  Description : Arduino Core for AVR microcontroller

 This package contains the source code and configuration files of the Arduino
 Core for Atmel's AVR microcontroller used on the Arduino Yún, Uno, Uno WiFi,
 Diecimila, Nano, Mega, MegaADK, Leonardo, Leonardo Ethernet, Micro, Esplora,
 Min, Ethernet, Fio, BT, LilyPadUSB, Lilypad, Pro, ATMegaNG, Robot Control,
 Robot Motor, Gemma, Yún Mini.
 .
 It also contains some basic interfaces for interacting with the
 internal non-volatile storage (aka EEPROM) in AVR based Arduino boards.
 Also interfaces for interacting with plugable USB infrastructure (HID),
 for the Serial Programming Interface (SPI), for serial communication on
 any digital pins and for communicaton by I2C and Two Wire Interfaces
 devices.

This package is a new dependency for an updated Arduino package.

It will be maintained within the Electronics team.

Bug#976710: O: z-push - open source implementation of the ActiveSync protocol

[Carsten Schoenert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: r...@1afa.com

I (as part of the pkg-giraffe team) intent to orphan src:z-push.

I don't have the time to maintain this package any longer or providing
package uploads.

>From src:z-push are various binary packages build. These binary packages
are useful for interaction of multi platform ActiveSync devices with any
groupware. One of the mainly used back ends is Kopano.

Maintenance if z-push isn't difficult nor costs a lot of time, but
requires some knowledge about the interaction to the possible back ends.

The current state of the package is that the version in Debian is quite
up to date.

The pkg-giraffe-team is happy to offer help and guidance for interested
people which want to work on z-push within Debian.

Regards
Carsten

Bug#976708: O: kopano-webapp - WebApp for the Kopano Collaboration Platform

[Carsten Schoenert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: j.vander...@kopano.com

I (as part of the pkg-giraffe team) intent to orphan src:kopano-webapp.

Guido and myself unfortunately doesn't have enough free time to maintain
this package any longer.
kopano-webapp is building various binary packages so users of kopano-core can 
access
their groupware account through a web browser. The main webapp is based
on PHP and Javascript libraries. There are additional binary packages
for integration of kopano-webapp within the various possible web
servers.

kopano-webapp is depending kopano-contacts and php-mapi from
src:kopanocore and is recommending kopano-server for interaction with
the back end.
The package itself is more or less up to date and not difficult to
maintain, but it's features are depending on newer versions of php-mapi
which is build by kopanocore.
Ther are some smaller outstanding issues which are reported to the BTS.

The pkg-giraffe-team is happy to offer help and guidance for interested
people which want to work on kopano-webapp within Debian.

Regards
Carsten

Bug#976709: O: kopano-webapp-plugins-files - Kopano WebApp plugin for managing attachments

[Carsten Schoenert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: j.vander...@kopano.com

I (as part of the pkg-giraffe team) intent to orphan src:kopano-webapp.

I don't have the time to maintain this package any longer.

kopano-webapp-files, which is the only binary package build up from
kopano-webapp-plugins-files, is depending from kopano-webapp.
Maintenance isn't difficult and rather straight forward.

The pkg-giraffe-team is happy to offer help and guidance for interested
people which want to work on kopano-webapp-plugin-files within Debian.

Regards
Carsten

Bug#976707: O: kopanocore - Complete and feature rich groupware solution

[Carsten Schoenert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: s.eisenm...@kopano.com

I (as part of the pkg-giraffe team) intent to orphan src:kopanocore.

Guido and myself unfortunately doesn't have enough free time to maintain
this package any longer.
kopanocore is an more complex package and is building a lot of related
binary packages. This package also has a very frequent upstream activity
due it's ongoing development. Unfortunately there isn't some upstream
LTS strategy for kopanocore and that makes it hard to provide some
useful care and updates (if required) for the Debian stable release. At
least this hasn't worked well for the release cycle of Debian Buster and
we expect this will also come true for the next stable release of
Debian, so the pkg-giraffe-team don't want to see kopanocore within
Debian Bulleseye.

Also upstream is now providing some new extra binary stuff around
kopanocore which is based on technologies that the pkg-giraffe team isn't
able to manage. Upstream is building things based on the Go language
e.g.

The pkg-giraffe-team is happy to offer help and guidance for interested
people which want to work on kopanocore (and also on related packages)
within Debian.

Regards
Carsten

Bug#963237: ITP: raritan-json-rpc-sdk -- JSON-RPC SDK for various Raritan product series like PDUs and Transfer Switches

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: raritan-json-rpc-sdk
  Version : 3.6.0
  Upstream Author : Raritan Inc. 
* URL : https://www.raritan.com/support/product/px3 (look for 
JSON-RPC Bindings)
* License : GPL+2, BSD-3
  Programming Lang: C#, Perl, Python, Java
  Description : JSON-RPC SDK for Raritan PDU product series PXE, PX2, PX3, 
PXC, PXO, PX3TS, BCM2 and EMX2

Raritan is providing various components around power distribution within
e.g. data center which all have a of course a network interface to
interact with.
Recent PDUs (Power Distribution Units) come along with a lot of features
for managing power switching and measurement, user management and more.
Raritan has integrated a powerful RestAPI within their products and is
providing library binding for C#, Perl, Python and Java by their
JSON-RPC SDK.
Contrary to other companies Raritan decided to provide their management
SDK by a DFSG compatible license. So far I know all other similar
products from other companies doesn't have FOSS libraries for managing
their components.

I use parts of the provided API on my day job to control a big amount
of PDUs in different cities. I intent to package the Python part and also
the Perl library with help from Gregor Herrmann (thx!).
C# and Java should be doable too but this needs volunteers as I don't
have enough experience for these languages and packaging.
Upstream is also providing a Doxygen generated documentation for the
JSON-RPC bindings.

https://help.raritan.com/json-rpc/pdu/v3.6.0/

I intent to package this too, right now only the pre build html, js and
CSS files are available. I'm in contact with upstream to get all
required files for getting this rebuild.

Regards
Carsten

Bug#950536: ITP: iconnect-tools -- system administration helping tools for Iomega iConnect

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: iconnect-tools
  Version : 0.1
  Upstream Author : Carsten Schoenert 
* URL : https://salsa.debian.org/tijuca/iconnect-tools
* License : MIT
  Programming Lang: Shell
  Description : system administration helping tools for Iomega iConnect

 The Iomega iConnect is a Marvell Kirkwood (ARM) Linux-based NAS device which
 comes with 4 USB ports, GbE and wireless support (802.11g).
 This package contains some small helpers for using a Debian installation
 on the Iomega iConnect.
 .
 It contains a systemd service file for controlling the info LEDs on the front
 of the device but also a simple UDEV rule and helper script to show recognized
 USB devices a user has plugged in. It also serve a Sysctl configuration
 file to decrease the sync rate of the Linux kernel for writing data to the
 swap file on a USB device.
 .
 The package provides also a configuration file for the u-boot-tools package
 so the U-Boot environment can be read and modified from a running Debian
 installation.

Additional notes
The Iomega iConnect is not a recent peace of hardware, it's about 10
years old but is still running without problems. As long Debian is
providing packages for the armel architecture this hardware will running
smoothly. The iConnect is avaialable for cheap money on Amazon or EBay
e.g.
I've recently adjusted the debian-installer as WIP and can install
Debian in the iConnect without further needed modifications (except the
U-Boot environment).

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

The people from OpenWRT have probably the best hardware overview if you
don't know about the Iomeag iConnect.

https://openwrt.org/toh/iomega/iconnect

Bug#941205: ITP: python-sphinxcontrib-svg2pdfconverter -- Sphinx SVG to PDF converter extension

[Carsten Schoenert]

Am 26.09.19 um 13:59 schrieb Thomas Goirand:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand 
> 
> * Package name: python-sphinxcontrib-svg2pdfconverter
>   Version : 0.1.0
>   Upstream Author : Stefan Wiehler 
> * URL : 
> https://github.com/missinglinkelectronics/sphinxcontrib-svg2pdfconverter
> * License : BSD-2-clause
>   Programming Lang: Python
>   Description : Sphinx SVG to PDF converter extension
> 
>  This extension converts SVG images to PDF in case the builder does not 
> support
>  SVG images natively (e.g. LaTeX).
> 
> Note: this is a new dependency of many OpenStack package, as they now support
> building docs using PDF format.

this seems already packaged.

https://bugs.debian.org/940121
https://tracker.debian.org/pkg/sphinxcontrib-svg2pdfconverter

-- 
Regards
Carsten Schoenert

Bug#930973: ITP: hiera-py -- Python language bindings for the hiera hierarchical database

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: hiera-py
  Version : 0.0.1
  Upstream Author : Thomas Van Doren 
* URL : https://github.com/agx/hiera-py
* License : BSD
  Programming Lang: Python
  Description : Python language bindings for the hiera hierarchical database

 Hiera is a key/value lookup tool for configuration data, often used in Puppet
 and created and built to make Puppet better and let you set node-specific data
 without repeating yourself.
 .
 Hiera’s hierarchical lookups follow a “defaults, with overrides” pattern,
 meaning you specify common data once, and override it in situations where the
 default won’t work.
 .
 The hierarchical data can be organised as JSON, YAML, and EYAML files.

Thomas Van Doren has created this Python library mainly in 2013 but has
the further development stopped some time ago and archived his tree on
GitHub.
The original GitHub tree is forked since than several times and on some
of these forks people have added some own needed features and partially
added also Python3 compatibility. By the help of Guido Guenther the
current packaging is already completely Python3 compatible.

We use this Python library on my day job because we can structure
configuration item for a lot of measurement devices really nicely.
Getting config items is really easy by this library.

 >>> import hiera
 >>> hiera_client = hiera.HieraClient('/etc/hiera.yml', environment='dev')
 >>> hiera_client.get('my_key')
 'my_value'

I will maintain this package on Salsa on
https://salsa.debian.org/tijuca/hiera-py (to be created).

Bug#923220: DFSG compliance concerns

[Carsten Schoenert]

Hello Philipp,

Am 03.03.19 um 16:55 schrieb Philipp Meisberger:
> Hi,
> 
> it is correct that the package just builds a .deb file which contains
> full functional Arduino IDE. Simple and clean.

maybe simple, but definitely not clean from a point of view of the DFSG!
And that's what Rock Storm has mentioned. All packages that are not
fulfilling the DFSG aren't Debian or can't be Debian and need to go to
non-free. But as it's possible to package the arduino IDE for main it
would be confusing for user to also find a arduino package in the
non-free sections.

> What about the java-package and DFSG? It is very similar to my package
> and also does not build a .deb from source but is contained in Debian.

Please have a look at the existing package arduino!
One of the most important files within the Debian packaging is the
copyright file.

https://salsa.debian.org/electronics-team/arduino/arduino/blob/master/debian/copyright

Please note the Files-Excluded field here, it is listing all the files
that are excluded so the package is DFSG clean.

Next there is a file README.source.

https://salsa.debian.org/electronics-team/arduino/arduino/blob/master/debian/README.source

It mostly describes what steps are needed to import a new source tarball
and how to handle the packaging if needed.

Packaging the arduino IDE isn't a nice package where new contributors
should start with (because of this massive DFSG stuff). Geert (CCd) was
one of the latest people who have worked on arduino so he could probably
say something about the current state of the arduino package. I'm not
familiar enough to give more advises regarding updating the arduino
package, I guess Geert can jump in. But I hardly won't see a non-free
arduino IDE package in Debian or a helper package in contrib.

-- 
Regards
Carsten Schoenert

Bug#923220: ITP: arduino-package -- Utility for creating Arduino Debian packages

[Carsten Schoenert]

Hello Phillip,

Am 25.02.19 um 09:12 schrieb Philipp Meisberger:
> Package: wnpp
> Severity: wishlist
> Owner: Philipp Meisberger 
> 
> * Package name: arduino-package
>   Version : 1.0
>   Upstream Author : Philipp Meisberger 
> * URL : https://github.com/philippmeisberger/arduino-package
> * License : D-FSL
>   Programming Lang: Shell
>   Description : Utility for creating Arduino Debian packages
> 
> This package provides the capability to build a Debian package from
> an Arduino binary distribution by running make-arduinopkg  archive file>. Download the archive file from https://www.arduino.cc
> 
> This package is a good addition to Debian since there seems no such
> application. I often use it. The package is no dependency for other
> packages. I am looking for a sponsor.
there exists already a package arduino-builder within the Electronics
team which does mostly the same as you probably intended to solve by
your package.

https://salsa.debian.org/electronics-team/arduino/arduino-builder

I suggest to get in contact with the people which do currently
maintaining this existing package.

-- 
Regards
Carsten Schoenert

Bug#920199: ITP: ponyprog -- Serial device programmer

[Carsten Schoenert]

Am 22.01.19 um 17:34 schrieb Andrej Shadura:
> Unbelievable, I didn’t know PonyProg is still being maintained. At
> some point in the past (2009?)

2009? Pah! :P
I think think the first time I've used Ponyprog was around 1999. ;)

-- 
Regards
Carsten

Bug#920199: ITP: ponyprog -- Serial device programmer

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: ponyprog
  Version : 3.0.0~rc0
  Upstream Author : Claudio Lanconelli 
Eduard Kalinowski 
* URL : https://github.com/lancos/ponyprog
* License : GPL-2+, LGPL-2.1
  Programming Lang: C++, 
  Description : Serial device programmer

 PonyProg is a serial device programmer software with a user friendly
 GUI framework available for Windows and Linux. Its purpose is reading
 and writing every serial device. With PonyProg and SI-Prog you can
 program Wafercard for SAT, eeprom within GSM, TV or CAR-RADIO.
 Furthermore it can be used as a low cost starter kit for PIC and AVR.
 .
 PonyProg supports AVR, SPI eeprom, AVR micro, 12C bus 8bit eeprom, PIC
 16 micro, PIC 12 micro, AT89S micro and SDE2506 eeprom family chips.
 .
 You can open any HEX, e2p, mot, csm, rom, eep, bin files and burn them
 to uC or PIC. You can even backup the old program on the chip using
 Ponyprog. Ponyprog enables the user to write, verify and erase data on
 the microchip.
 .
 Set fuse bits and locks using PonyProg. You can save any HEX file to
 BIN file or eep file,BIN file to HEX file or MOT file and vice versa so
 you can use Ponyprog as converter too. PonyProg offers serial or
 parallel port programming for uC's. You can even change polarity of
 control lines without touching the wires using I/O port setup.
 .
 Using Ponyprog together with generic USB2serial adapters is currently
 not possible! There are plans by upstream to use libusb to add such
 functionality.

This package will be maintained within the Debian Electronics team.
Co-maintainers are welcome!

Regards
Carsten

Bug#881379: Retitle #881379 to ITP

[Carsten Schoenert]

I played around with CardBook and picked up the packaging thing Minkush
hast done and merged all together into git tree + git-buildpackage based
Debian workflow.

If someone want's to pick up feel free to take the git tree from

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

and adjust to your needs. I've installed the package that is built from
the source but didn't have done any deeper testing.

The packaging is using mozilla-devscripts with the web_ext debhelper
snippet so the package name is fulfill the current name schema related
to the introduction of WebExtension in FF and TB.

Also feel free to ask for a sponsorship if required.

Regards
Carsten

Bug#906853: ITP: tbsync -- [Thunderbird Add-On] Sync contacts, tasks and calendars to thunderbird. Currently supporting Exchange ActiveSync (EAS) and sabre/dav (CalDAV & CardDAV)

[Carsten Schoenert]

Hello Hednrik,

On Tue, Aug 21, 2018 at 09:45:19PM +0200, Hendrik Sattler wrote:
...
> >Synchronize Exchange ActiveSync accounts (contacts, tasks and
> >calendars) to Thunderbird, supports Office 365, Outlook.com,
> >Freenet, Strato, Hotmail, Kopano and other EAS compatible servers.
> 
> While this is a long list, none of these are free software. Maybe you
> can add compatible free software servers? (Horde?)

if you know some FOSS based server TbSync that is also working with this
AddOnn I'd say it's absolutely no problem to add them to the list too.
The list of possible use cases here is mostly longer than for the
proprietary products. So far I know the main intention behind TbSync
(and other connectors) was to add the possibility to let Thunderbird and
the Lightning AddOn also use some proprietary backends that are
unfortunately really common in bigger 'professional' environments.

> Also "EAS compatible" is very unspecific, it usually refers to a
> minimum and maximum supported version.

EAS is a abbreviation for Exchange Actice Sync as you know for sure. So
it's very obvious which product is behind that protocol. For the short
description of this package the description is absolutely correct. The
points you meant is something for the long description and/or some
extra Readme file within the package.

If you feel uncomfortable with the package description please take some
time and provide a patch which could be applied later or at least
provide some modified text that the maintainer can later use to improve
the package description.

Unspecific things like 'this could' or 'this isn't' aren't really
helpful, most of the maintainers I know are open for improvements if
they are done in a constructive way.

Please also note, this here is an ITP report. The meaning is basically
to show other people that someone is intended to package a software. I
agree mostly on your points, but don't be disappointed if the package
will start in package without your points reconsidered.

Regards
Carsten

Bug#905134: ITP: libcoap2 -- C-Implementation of CoAP, API version 2

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: libcoap2
  Version : 4.2.0alpha
  Upstream Author : Olaf Bergmann 
* URL : https://libcoap.net
* License : BSD-2-clause
  Programming Lang: C
  Description : C-Implementation of CoAP, API version 2

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 existing libcoap package in the archive isn't able to use
any cryptography features. libcoap2 will provide an updated library
which also provides encryption based on the library libssl1.1. It's
planned to also support encryption based on GnuTLS at a later time. A
first RC is expected to be released soon.

The resulting upstream modifications to libcoap are not backwards
compatible. To keep the existing library coinstallable with the current
version I want to package the newest version within a separate source
package.

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

Regards
Carsten

Bug#903954: ITP: sphinxcontrib-restbuilder -- Sphinx extension to build reST (reStructuredText) files

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: sphinxcontrib-restbuilder
  Version : 0.2
  Upstream Author : 2012-2013, Freek Dijkstra (gnidan) 
* URL : https://github.com/sphinx-contrib/restbuilder
* License : BSD-2-clause
  Programming Lang: Python
  Description : Sphinx extension to build reST (reStructuredText) files

 This extension is in particular useful to use in combination with the
 autodoc extension to automatically generate documentation for use by any
 rst parser (such as the GitHub wiki).
 .
 In itself, the extension is fairly straightforward -- it takes the
 parsed reST file from Sphinx and outputs it as reST.

This package is a build dependency for python-ilorest (#903953).

As for python-ilorest I'm happy to find people who interested in
co-maintaining. The package should be python3 ready now since upstream
made some small adjustments recently.

Regards
Carsten

Bug#903953: ITP: python-ilorest -- Python based library for HPE iLO RESTful API on HPE iLO 4 and iLO 5

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: python-ilorest
  Version : 2.3.1
  Upstream Author : 2016-2018 Hewlett Packard Enterprise Restful API Group
Jack Garcia 
Matthew Kocurek 
Prithvi Subrahmanya 

* URL : https://github.com/HewlettPackard/python-ilorest-library
* License : Apache2.0
  Programming Lang: Python
  Description : Python based library for HPE iLO RESTful API on iLO 4 and 
iLO 5

 The Python iLO RESTful library is the platform on which the HPE RESTful
 tool was built on. It’s main purpose is to simplify the inband and
 outband communication to the HPE RESTful API. The HPE RESTful API for iLO
 is a RESTful application programming interface for the management of iLO
 and iLO Chassis Manager based HPE servers. REST (Representational State
 Transfer) is a web based software architectural style consisting a set
 of constraints that focus on a system’s resource. HPE REST library
 performs the basic HTTP operations GET, POST, PUT, PATCH and DELETE on
 resources using the HATEOS (Hypermedia as the Engine of Application)
 REST architecture. The API allows the clients to manage and interact
 with iLO through a fixed URL and several URIs.

I've to deal with HPE hardware and servers mostly every day and the
python library provided by HPE seems to be useful for managing mass
configuration of that hardware. As HPE is one of the main contributors
of the Debian project and also using hardware from HPE I guess it's
worth to package this library.

The source is also providing a Sphinx based documentation and some
examples how to library can be used.

I'm not an experienced Python library packaging person so I'm happy to
find other people to co-maintain this library, talk to me on DC18 please
or by email!

So far I could read and study the ilorest-library isn't fully python3
ready, I'd start by packaging only the python2 variant for now.

Regards
Carsten

Bug#898400: RFP: sccache -- Shared Compilation Cache for Rust

[Carsten Schoenert]

Package: wnpp
Severity: wishlist

* Package name: sccache
  Version : 0.2.6
  Upstream Author : Mozilla GitHub 
* URL : https://github.com/mozilla/sccache
* License : Apache 2.0
  Programming Lang: Rust, Markdown, Shell
  Description : Shared Compilation Cache for Rust

sccache is a ccache-like tool. It is used as a compiler wrapper and
avoids compilation when possible, storing a cache in a remote storage
using the Amazon Simple Cloud Storage Service (S3) API, the Google Cloud
Storage (GCS) API, or Redis if wanted.

sccache can also be used with local storage instead of remote.

It works as a client-server. The client spawns a server if one is not
running already, and sends the wrapped command line as a request to the
server, which then does the work and returns stdout/stderr for the job.
The client-server model allows the server to be more efficient in its
handling of the remote storage.

We all know of ccache [1], a wrapper for compiler calls to gcc or g++.
sccache does the same for Rust code and can keep compile time of the
source at a minimum. Firefox and Thunderbird, which is still based
mostly on the code of Firefox, are using Rust as programming language
more and more and building them take now a lot of time.

Firstly the availability of sccache will help to get Firefox and
Thunderbird packages more qickly while doing testing builds, but all
other Rust based projects with their source code will benefit from
sccache.

[1] https://ccache.samba.org/

Regards
Carsten

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

[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#888489: ITP: ngspice-dfsg -- Spice circuit simulator - DFSG compatible parts

[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#888489: ITP: ngspice-dfsg -- Spice circuit simulator - DFSG compatible parts

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert <c.schoen...@t-online.de>

* 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#888476: ITP: kicad-templates -- read to use project templates for KiCad

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert <c.schoen...@t-online.de>

* 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#888116: ITP: kicad-packages3d -- 3d model libraries for KiCad's Pcbnew editor

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert <c.schoen...@t-online.de>

* 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#888108: ITP: kicad-footprints -- footprint libraries for KiCad's Pcbnew editor

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert <c.schoen...@t-online.de>

* 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#888104: ITP: kicad-symbols -- schematic symbols for KiCad's eeschema

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert <c.schoen...@t-online.de>

* 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#865521: lintian: check for embedded-pear-module needs to be more granular for unstable/testing/stretch

[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
<pra...@swecha.net> 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#881424: RFP: ausweisapp2 -- online authentication using German identity document

[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