Bug#1075986: ITP: rotatepdf -- A simple utility to rotate PDF documents.

[Andrej Shadura]

Hi,

On Tue, 9 Jul 2024, at 03:03, Joseph Warner wrote:
> Rotate PDF files in place. Rotatepdf is a wrapper around PDFtk.
> Terminal usage and several GUI-based file managers are supported.
>
> Why?
> Provide a simpler method to rotate entire PDF files than PDFtk itslef, which
> is very powerful but extremely complicated for such a simple use case.
>
> Additionally, provide the option to install file manager scripts so
> that PDF files can be rotated from the GUI via the right-click
> context menu.
>
> Maintenance?
> I should be capable of maintaining the package myself.

Don’t we already have quite a few utilities that do this? For GUI, pdfchain is 
one example.

-- 
Cheers,
  Andrej

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi again,

On Tue, 21 May 2024, at 17:59, Andrej Shadura wrote:
> On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
>> Well I ended packaging this, it's waiting in debcargo-conf at
>> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653
> 
> If the Rust impl of toml2json works better than one written in Python 
> (reserialize), I’m more than happy that you take over the binary package. I’m 
> almost certain it does, given that the Python package is basically someone’s 
> script I packaged and patched over and over again.

In fact, having checked the source code, it’s one way only, and after all it’s 
also someone else’s quick hack. Maybe someone should write a robust tool to 
support all formats and directions and package *that* for Debian? :)

-- 
Cheers,
  Andrej

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi,

On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
> On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:
>> Quoting Facundo Gaich (2024-02-22 17:12:22)
>> > I can work on packaging this if you're still interested, I'd need a 
>> > sponsor.
>> > 
>> > I've already done some preliminary work on this, in particular I renamed
>> > the bin to "rust-toml2json" but maybe you've got a better idea?
>> 
>> If the command-line tool does somewhat the same as the existing one, I
>> suggest to rename it with the deviating part as the end instead, so that
>> users TAB-completing would easier notice the alternative:
>> toml2json-rust. 
> 
> Well I ended packaging this, it's waiting in debcargo-conf at
> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

If the Rust impl of toml2json works better than one written in Python 
(reserialize), I’m more than happy that you take over the binary package. I’m 
almost certain it does, given that the Python package is basically someone’s 
script I packaged and patched over and over again.

-- 
Cheers,
  Andrej

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Hi,

On Sun, 21 Jan 2024, at 21:06, Jonas Smedegaard wrote:
> Just a notice that I am still working on this.  If you want to follow my
> work more closely, then I can put up my fork of the git repo somewhere,
> but if you won't be looking closely anyway, then I will not bother
> setting that up, and instead simply shout out when I have something
> more substantially working.

Thank you for this. I don’t have to time to look at this myself at the moment, 
but tarzeau (cc'd) expressed some interest.

-- 
Cheers,
  Andrej

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Hello,

On 16/11/2023 18:14, Jonas Smedegaard wrote:

Upstream project consist of multiple crates released in sync - which is
a pattern that is only inefficiently handled by the Rust team (by
needlessly packaging each individual crate as a separate Debian source
package).

Unless you particularly are asking the Rust team for help here, then I
can offer to help: I have experience with handling this type of Rust
source code structure, and would be happy for this opportunity to
collaborate more closely with you, Andrej.


Yes, I’m aware of that, that’s why I packaged it separately from the 
debcargo-conf-managed packages. Nevertheless, the dependencies can be 
managed using debcargo-conf workflow (and that’s what I did when I still 
had energy to spend on this package).


In any case, I’ll be happy with any help that can be had with this 
package, whether it’s updating/packaging build dependencies as separate 
packages or by following the debcargo-conf workflow, and from anyone — 
you, Jonas, included :)


Thanks!

--
Cheers,
  Andrej

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: re...@packages.debian.org, debian-de...@lists.debian.org, Rust 
Maintainers 
Control: affects -1 + src:resvg

Hi all,

resvg is a command-line SVG renderer which I introduced to Debian back
in 2019. Unfortunately, very soon after the initial upload the upstream
has rewritten substantial parts of resvg, which resulted in it requiring
build dependencies that were missing from Debian at that point. I tried
to update resvg and upload the missing dependencies, but ultimately
never completed that work, and resvg was removed from bookworm.

Unfortunately, I cannot invest any more time into resvg at the moment,
so I have to officially request assistance with maintaining the resvg package.

To the Debian Rust team: if you can, please adopt this package.

Thank you.

The package description is:
 resvg is a command-line utility to render SVG files based on a static
 SVG Full 1.1 subset. It is a fast, small, portable, multiple
 backend SVG library designed for edge-cases.
 .
 resvg supports Cairo and Qt backends.

Bug#953888: ITP: aioquic -- QUIC and HTTP/3 implementation in Python

[Andrej Shadura]

Hello,

On Wed, 26 Jul 2023, at 05:45, Scott Kitterman wrote:
> On Tue, 25 Jul 2023 17:28:27 -0400 Scott Kitterman  
> wrote:
> ...
>> After three years, I'm now assuming this isn't a priority for you.  Please
>> let me know if you do intend to work on this soon as I now need it for
>> dnspython, so I plan to package it if I don't hear back.
>> 
> I've uploaded pylsqpack, which is needed as a dependency for this, to New. 
> Once it's in the archive, I'll got ahead with aioquic.

Thanks for this, please proceed with aioquic too.

This somehow fell off my radar completely. I guess, the need for that package 
disappeared for me, and I forgot to switch it to RFP. Sorry :)

-- 
Cheers,
  Andrej

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Andrej Shadura]

Hi,

On Mon, 24 Jul 2023, at 16:16, Daniel Gröber wrote:
> tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> performance will be much better.
>
> I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)

As the maintainer of tayga, I’ll be happy to sponsor tundra too :)

-- 
Cheers,
  Andrej

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Andrej Shadura]

Hi,

On Fri, 2 Jun 2023, at 20:42, Gioele Barabucci wrote:
> On 02/06/23 20:25, Andrej Shadura wrote:
>>> This (current?) limitation should be mentioned in the short and long
>>> descriptions.
>> 
>> It does in fact work with anything, as long as has a PKCS #11 provider.

> The README on GitHub says:

>  > Momentálne podporujeme na Slovensku bežne používané karty
>  > a ich ovládače:
>  >
>  > * občiansky preukaz (eID klient)
>  > * I.CA SecureStore
>  > * MONET+ ProID+Q
>  > * Gemalto IDPrime 940
>  >
>  > Doplniť ďalšie je pomerne ľahké pokiaľ používajú PKCS#11.

> I read this as "Support for other kinds of eIDs is _possible and easy_ 
> as long as they support PKCS#11, but _not automatic_". Am I reading this 
> wrong?

Well, I suspect they want to be on the safe side, but OTOH I have not verified 
it. Given that some of the Autogram’s dependencies are still not in Debian, I 
reckon this can either be solved upstream by the time the package is ready, or 
I can add a disclaimer to the package description.

-- 
Cheers,
  Andrej

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Andrej Shadura]

Hi,

On Fri, 2 Jun 2023, at 20:13, Gioele Barabucci wrote:
> On 02/06/23 13:28, Andrej Shadura wrote:
>>Description : eIDAS-compliant document signing tool
>> 
>> Autogram is a cross-platform (Windows, MacOS, Linux) desktop JavaFX
>> application to sign documents accordancing to the eIDAS standard.
>> The user can use it to sign files directly, or the application can be
>> easily integrated into your own (web) information system using the
>> HTTP API.
>
> The documentation hints at the fact that this application works only in 
> conjunction with Slovenian eIDs.

It's Slovak, not Slovenian.

> This (current?) limitation should be mentioned in the short and long 
> descriptions.

It does in fact work with anything, as long as has a PKCS #11 provider.

-- 
Cheers,
  Andrej

Bug#1037037: RFP: eu-dss -- EU Digital Signature Service implementation

[Andrej Shadura]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Java Maintainers 
, team+ei...@tracker.debian.org

* Package name: eu-dss (?)
  Version : 5.12
  Upstream Contact: David Naramski, Pierrick Vandenbroucke, Aleksandr Beliakov 
et al
* URL : https://github.com/esig/dss

https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/Digital+Signature+Service+-++DSS
* License : LGPL-2.1
  Programming Lang: Java
  Description : EU Digital Signature Service implementation

DSS (Digital Signature Services) is an open-source software library for 
electronic signature creation
and validation in line with European legislation.

In particular, DSS aims to follow the eIDAS Regulation and related standards 
closely.

DSS can be re-used in an IT solution for electronic signatures to ensure
that signatures are created and verified in line with European legislation
and standards. DSS allows re-use in a variety of different ways: in an
applet, in a stand-alone application or in a server application. DSS
can also be used as a reference implementation for IT solutions which
do not directly re-use it. Demos are also available to assist the use of
DSS as a reference implementation. DSS was developed by Nowina Solutions
and is maintained up-to-date via new releases.

This package is a dependency of the Autogram eIDAS signing tool.

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+ei...@tracker.debian.org

* Package name: autogram
  Version : 1.99.10
  Upstream Contact: Jakub Ďuraš, Slovensko.Digital et al.
* URL : https://github.com/slovensko-digital/autogram
* License : EUPL 1.2
  Programming Lang: Java
  Description : eIDAS-compliant document signing tool

Autogram is a cross-platform (Windows, MacOS, Linux) desktop JavaFX
application to sign documents accordancing to the eIDAS standard.
The user can use it to sign files directly, or the application can be
easily integrated into your own (web) information system using the
HTTP API.

Bug#1036169: ITP: jl -- Pretty Viewer for JSON logs

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: jl
  Version : 0.1.0-1
  Upstream Author : Yunchi Luo
* URL : https://github.com/mightyguava/jl
* License : Expat
  Programming Lang: Go
  Description : Pretty Viewer for JSON logs

 jl (JL) is a parser and formatter for JSON logs, making machine-readable
 JSON logs human readable again.
 .
 jl currently supports 2 formatters, with plans to make the formatters
 customizable.
 .
 The default is -format compact, which extracts only important fields from
 the JSON log, like message, timestamp, level, colorizes and presents
 them in a easy to skim way. It drops un-recongized fields from the logs.
 .
 The other option is -format logfmt, which formats the JSON logs in a way
 that closely resembles logfmt (https://blog.codeship.com/logfmt-a-log-
 format-thats-easy-to-read-and-write/). This option will emit all fields from
 each log line.

Packager’s comment:

I’m not sure which binary name should I choose, since jl is a bit too short,
and provides an opportunity for a future name collision. Please comment and
let me know if you have a better idea.

I think in any case it makes sense to name the source package
golang-github-mightyguava-jl.

-- 
Cheers,
  Andrej

Bug#1030780: Maintainers wanted for softether-vpn

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org

Hi all,

I packaged SoftEther VPN back in 2020 when people in Belarus protested against 
decades of dictatorship, and they needed a safe way to communicate with the 
outside world and with each other, circumventing the state censorship.

Since then, due to a massive crackdown on protests and repressions against 
anyone remotely involved, most of my friends have moved abroad, and I, 
personally, don't know a single user of this VPN right now. Packaging is not 
hard, but not super trivial either, and requires some work to package 
subsequent releases. Not using this software myself, I'm really not in position 
to continue being the maintainer, and if nobody takes it over, I will have to 
orphan it eventually.

Please let me know if you can help.

-- 
Cheers,
  Andrej

Bug#1029371: ITP: libgis-distance-perl -- Perl module to calculate geographic distances

[Andrej Shadura]

Control: submitter -1 Florian Schlichting 

Hi,

On Sat, 21 Jan 2023 22:36:26 +0100 Florian Schlichting wrote:

> From: Florian Schlichting @fschlich.dialup.fu-berlin.de

I believe your reportbug is misconfigured.

--
Cheers,
  Andrej

Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects

[Andrej Shadura]

Hi,

On Sun, 12 Jun 2022, at 21:51, Domenico Andreoli wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Domenico Andreoli 
>
> * Package name: golang-k8s-apimachinery
>   Version : 1.25.0~alpha0-1
>   Upstream Author : Kubernetes
> * URL : https://github.com/kubernetes/apimachinery
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : Handle Kubernetes-like API objects.
>
>  This library is a shared dependency for servers and clients to work with
>  Kubernetes API infrastructure without direct type dependencies. Its
>  first consumers are k8s.io/kubernetes, k8s.io/client-go, and
>  k8s.io/apiserver.

Good luck :)

-- 
Cheers,
  Andrej

Bug#984462: Proposing to replace ruby-uglifier with ruby-terser and remove ruby-uglifier

[Andrej Shadura]

Hi,

On Sun, 5 Jun 2022, at 12:58, Pirate Praveen wrote:
> On ബു, ജൂൺ 1 2022 at 07:32:00 വൈകു +05:30:00 
> +05:30:00, Pirate Praveen  wrote:
>> Looks like upstreams moved already
>> https://github.com/rails/sprockets/pull/713
>> https://github.com/rails/rails/blob/main/Gemfile#L33
>
> $ reverse-depends -b ruby-uglifier
> Reverse-Build-Depends
> * open-build-service
>
> $ reverse-depends ruby-uglifier
> Reverse-Depends
> * diaspora
> * gitlab
> * obs-api

> Last unstable upload of open-build-service/obs-api is 2020-04-13 and 
> already has two unfixed rc bugs and a request for help 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984462

We (Collabora) stopped using OBS from Debian packages and switched to our own 
Docker images completely, which use Rubygems.org instead. Since we were 
effectively the maintainers of the Debian packages, and nobody else volunteered 
to maintain OBS in Debian, I’m going to remove most of it except the worker 
code, which is really tiny and needs virtually no maintenance. (There’s also a 
related package, obs-build, unaffected by this.)

I’m preparing an upload to the OBS package to implement this.

[0]: https://gitlab.collabora.com/obs/open-build-service

-- 
Cheers,
  Andrej

Bug#1010899: ITP: python3-pyst -- Python module for interacting with the Asterisk PBX

[Andrej Shadura]

On Thu, 12 May 2022 16:38:10 +0200 Bernd Schumacher  wrote:

Package: wnpp
Severity: wishlist
Owner: Bernd Schumacher 

* Package name: python3-pyst
  Version : 0.8
  Upstream Author : Ralf Schlatterbeck 
* URL : https://github.com/schlatterbeck/pyst.git
* License : LGPL, PSFL
  Programming Lang: Python
  Description : Python module for interacting with the Asterisk PBX

Pyst consists of a set of interfaces and libraries to allow programming of
Asterisk from python. The library currently supports AGI, AMI, and the
parsing of Asterisk configuration files. The library also includes debugging
facilities for AGI.

In debian buster an older python2 version of pyst called python-pyst is already
maintained by Apollon Oikonomopoulos .

Now pyst supports also python3.
Apollon Oikonomopoulos told me he is a bit short on time these days,
and I could feel free to file an ITP and "adopt" the package.
Ralf Schlatterbeck told me, he likes to see the a debian python3-pyst pakage.


I think it’s worth keeping the original repository and the source 
package name to preserve the continuity.


Feel free to ping me to review and upload your packaging when you feel 
ready.


--
Cheers,
  Andrej

Bug#1010899: ITP: python3-pyst -- Python module for interacting with the Asterisk PBX

[Andrej Shadura]

On 13/05/2022 15:29, Andrej Shadura wrote:
In debian buster an older python2 version of pyst called python-pyst 
is already

maintained by Apollon Oikonomopoulos .

Now pyst supports also python3.
Apollon Oikonomopoulos told me he is a bit short on time these days,
and I could feel free to file an ITP and "adopt" the package.
Ralf Schlatterbeck told me, he likes to see the a debian python3-pyst 
pakage.


I think it’s worth keeping the original repository and the source 
package name to preserve the continuity.


Feel free to ping me to review and upload your packaging when you feel 
ready.


Oh, I didn’t realise you ARE in fact a DD and have upload rights :) 
Nevermind then, but if you want a pair of eyes to have a look at your 
stuff, feel free to prod anyway :D


--
Cheers,
  Andrej

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Andrej Shadura]

Hi,

On Fri, 15 Apr 2022, at 17:55, Axel Beckert wrote:
> Andrej Shadura wrote:
>> On Fri, 15 Apr 2022, at 16:23, Axel Beckert wrote:
>> > Acoording to
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
>> > attached) the ruby-curses package in Debian is orphaned since at least
>> > April 2020 (last upload April 2018) as both the team listed in the
>> > Maintainer field as well as the person listed in the Uploaders field
>> > (all X-Debbugs-CC'ed) stated back then, that they are not maintaining
>> > this package. And there was no new upload since then either.
>> 
>> Thanks for filing this bug. I have uploaded a newer release, pushed
>> the Git changes to Salsa and will attempt to move it to the Ruby
>> team.
>
> Thanks a lot! That's really an unexpected and positive surprise!
>
> Shall I close this bug already again as you still seem to care about
> ruby-curses in contrary to what you stated back in 2020?

No, I still don’t intend to continue maintaining it 
I originally packaged it as a dependency of a Ruby implementation of 
git-crecord which I wanted to package. However, I quickly became unsatisfied 
with it and instead ported the Python code of hg-crecord to Git, so ruby-curses 
became useless to me.
If your package uses ruby-curses, it would be great if you could maintain this 
package in the Ruby team.

-- 
Cheers,
  Andrej

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Andrej Shadura]

Hi,

On Fri, 15 Apr 2022, at 16:23, Axel Beckert wrote:
> Acoording to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
> attached) the ruby-curses package in Debian is orphaned since at least
> April 2020 (last upload April 2018) as both the team listed in the
> Maintainer field as well as the person listed in the Uploaders field
> (all X-Debbugs-CC'ed) stated back then, that they are not maintaining
> this package. And there was no new upload since then either.

Thanks for filing this bug. I have uploaded a newer release, pushed the Git 
changes to Salsa and will attempt to move it to the Ruby team.

-- 
Cheers,
  Andrej

Bug#900928: RFP: fractal -- Matrix group messaging app

[Andrej Shadura]

Hi,

On Tue, 12 Apr 2022, at 12:23, Jonas Smedegaard wrote:
> Control: owner -1 !
>
> @Andrej: I took your silence to mean that you stopped working on this - 
> feel free to take back this ITP if I am mistaken.

Yeah, I've been quite busy lately and I was unable to work on this package. 
Sorry for not replying, I didn’t have time back then and then I forgot 

> Quoting Antoine Beaupré (2022-03-17 15:51:22)
>> Is there any progress on the packaging of fractal in Debian? Any 
>> blockers or missing crates?
>
> I have now put together a draft source package, tracked at 
> https://salsa.debian.org/matrix-team/fractal
>
> It compiles, also in an non-networked build environment if first 
> fetching 428 Rust crates (see debian/README.source).
>
> Build takes ~40 minutes on my local amd64 system.
>
> The built executable segfaults, however:
>
>> $ LANG=C fractal
>> 
>> (fractal:354481): GLib-GIO-ERROR **: 12:02:22.755: Settings schema 
>> 'org.gnome.Fractal' does not contain a key named 'markdown-active'
>> Sporings-/stoppunkts-fælde (smed kerne)
>
> That last message oddly ignores the LANG variable - it says something 
> like "Tracing/stoppoint trap (threw core)" which I guess essentially 
> means a segfault.
>
> My plan is to continue refine this package until suitable for release 
> into Debian, and then maintain it in the Matrix team.

It would be great if you could get the Rust team involved, as the majority of 
the dependencies should go in there. I started packaging dependencies for the 
non-next-Fractal back in the day, but the crypto stuff (for secret-service) was 
taking ages to get through NEW, which is why I gave up at some point.

-- 
Cheers,
  Andrej

Bug#1006872: RFH: apparmor -- user-space parser utility for AppArmor

[Andrej Shadura]

Hi,

On Mon, 7 Mar 2022, at 10:17, intrigeri wrote:
> But regarding maintenance of src:apparmor itself, the bus factor of in Debian 
> is
> 1, which is not great. I don't feel comfortable with this situation.
>
> src:apparmor includes:
>
>  - system initialization bits
>
>  - AppArmor parser, which is required to compile AppArmor profiles and load 
> them
>into the kernel for use by the AppArmor Linux Security Module
>
>  - abstractions, i.e. reusable bits of policy
>
> The workload is not particularly big: I would say a few hours per month
> on average.
>
> Upstream is very cooperative.

This reminded me I promised to work on dh-apparmor. I should find time for 
that, maybe also for apparmor itself.

-- 
Cheers,
  Andrej

Bug#1004030: O: lqa -- LAVA QA tool

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: de...@lists.apertis.org
Control: affects -1 src:lqa

I intend to orphan the lqa package.

This package offers an alternative command-line client to LAVA, the
automated testing platform. I was developed by a former colleague of
mine, but we no longer use this tool, so it is effectively also
abandoned upstream.

Should somebody find this tool interesing or useful, please get in touch
and take it over upstream as well.

-- 
Cheers,
  Andrej

Bug#1003796: ITP: ifupdown-ng -- network device manager compatible with ifupdown

[Andrej Shadura]

Hi Daniel,

On Sat, 15 Jan 2022, at 23:31, Daniel Gröber wrote:
> * Package name: ifupdown-ng
>   Version : 0.11.3
>   Upstream Author : Ariadne Conill 
> Maximilian Wilhelm 
> * URL : https://github.com/ifupdown-ng/ifupdown-ng
> * License : ISC
>   Programming Lang: C, Shell
>   Description : network device manager compatible with ifupdown
>
> ifupdown-ng is a network device manager which is backwards compatible with
> traditional ifup and ifdown as used on Debian and Alpine systems, while
> solving many design deficits with the original approach through robust
> error handling and the use of a dependency-solver to determine interface
> bring-up order.
>
> Unlike ifupdown2 (already in Debian) ifudown-ng's core is written in plain
> C with "executors" written in Shell talking to the kernel and system
> services, making it quite light yet easy to extend.
>
> See also Maximilian Wilhelm's Debconf21 talk:
>   
> https://debconf21.debconf.org/talks/52-contemporary-networking-configuration-with-ifupdown-ng/
>
> I plan on maintaining this package by myself, however I am looking for
> a sponsor.

I would be happy to sponsort ifupdown-ng for you.

-- 
Cheers,
  Andrej

Bug#1001894: ITP: spacecadetpinball -- Decompilation and port of "3D Pinball for Windows - Space Cadet"

[Andrej Shadura]

Hi,

On Sat, 18 Dec 2021, at 17:03, Lucy M wrote:
> * Package name: spacecadetpinball
>   Version : 2.0
>   Upstream Author : Andrey Muzychenko
> * URL : https://github.com/k4zmu2a/SpaceCadetPinball
> * License : MIT
>   Programming Lang: C++
>   Description : Decompilation and port of "3D Pinball for Windows - 
> Space Cadet"
>
> Reverse Engineered Decompilation of "3D Pinball for Windows - Space Cadet",
> Ported to be cross-platform.
>
> Doesn't contain the original (proprietary) data files, but requires them to 
> run.
> These are to be sourced seperatly. and placed in a relevent dir.
> Free assets do not exist yet, but may be possible in future (upstream issue 
> #96)

I’m afraid the fact this source has been obtained as the result of a 
decompilation of the original proprietary binary means this project cannot be 
legally under the MIT license. If this is true, it cannot be included in Debian 
main or contrib, and possibly not even in non-free.

-- 
Cheers,
  Andrej

Bug#1001468: ITP: pyproject2setuppy -- install pyproject.toml-based packages using plain setuptools

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 


* Package name: pyproject2setuppy
  Version : v21
  Upstream Author : Michał Górny 
* URL : https://github.com/mgorny/pyproject2setuppy
* License : BSD-2-Clause
  Programming Lang: Python
  Description : install pyproject.toml-based packages using plain setuptools

The original description:

 pyproject2setuppy is a tool to install pyproject.toml-based packages
 using plain setuptools. It maps the project metadata into setup() call
 arguments, making it possible to build them without installing the
 dependencies of the new build systems.
 .
 Supported features
 .
 Currently the following build systems are supported:
 .
  * flit
  * poetry
 .
 Only minimal build/install functionality is supported. Dependencies and
 sdist-related information are not propagated.
 .
 Scripts and entry points are not supported at the moment. This is subject
 to change in the future.

I plan to write a debhelper plugin to allow using this script together
with pybuild and dh-python.

Bug#813024: RM: libixp -- ROM; no longer used anywhere in Debian

[Andrej Shadura]

Control: reassign 813024 ftp.debian.org

Hi,

On Thu, 28 Jan 2016 16:23:01 +0100 Andrej Shadura 
wrote:

I'm orphaning the libixp package, since I do not use it any longer.


Nothing has changed since 2016 when I orphaned the package, except wmii, 
which was the only user of libixp, is no longer in Debian.


Please remove libixp from Debian testing and unstable.

--
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hi,

On Mon, 25 Oct 2021, at 06:25, Michael Kogan wrote:
> Hi, guys! Any news here? People are asking for a Debian package and I don't 
> know what to tell them: https://github.com/shutter-project/shutter/issues/417

There’s been no news since I uploaded Shutter to NEW a month ago: 
https://ftp-master.debian.org/new/shutter_0.98-1.html

-- 
Cheers,
  Andrej

Bug#996973: ITP: msc-generator -- Draws signalling charts from textual description

[Andrej Shadura]

Hi,

On Thu, 21 Oct 2021, at 20:43, Gábor Németh wrote:
> * Package name: msc-generator
>   Version : 7.0.1
>   Upstream Author : Zoltan Turanyi 
> * URL : https://sourceforge.net/p/msc-generator/
> * License : AGPL
>   Programming Lang: C++
>   Description : Draws signalling charts from textual description

> I am already packaging it in my Ubuntu Launchpad PPA, and it is used by some
> (including myself). I wish to bring it to Debian proper though.
> I can maintain the package myself, but need a sponsor.

msc-generator seems interesting; feel free to ping me for a review/upload when 
you’ve got something :)

-- 
Cheers,
  Andrej

Bug#996574: ITP: golang-k8s-kube-openapi -- Kubernetes OpenAPI spec generation & serving

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-k8s-kube-openapi
  Version : 0.0~git20211014.b3fe75c-1
  Upstream Author : Kubernetes
* URL : https://github.com/kubernetes/kube-openapi
* License : Apache-2.0
  Programming Lang: Go
  Description : Kubernetes OpenAPI spec generation & serving

 Kube OpenAPI This repo is the home for Kubernetes OpenAPI discovery
 spec generation. The goal is to support a subset of OpenAPI features
 to satisfy kubernetes use-cases but implement that subset with little
 to no assumption about the structure of the code or routes. Thus, there
 should be no kubernetes specific code in this repo.
 .
 There are two main parts:
  - A model generator that goes through .go files, find and generate model
 definitions.
  - The spec generator that is responsible for dynamically generate
 the final OpenAPI spec using web service routes or combining
 other OpenAPI/Json specs.  Contributing Please see CONTRIBUTING.md
 (CONTRIBUTING.md) for instructions on how to contribute.

Bug#972674: ITP: toolbox -- Unprivileged container development environment

[Andrej Shadura]

Hi,

On Wed, 10 Feb 2021 15:28:29 -0300 Andre Moreira Magalhaes
 wrote:
> Hi,
> 
> I ended up using this packaging as base for Endless OS and pushed
> the updated packaging to
> https://salsa.debian.org/andrunko-guest/toolbox/ (incl. update to
> 0.0.99).
> 
> The packaging still needs some work, specially regarding the two extra
> modules not yet packaged in Debian (see "debian/gocode"), but it works
> fine as is.
> 
> I also checked about using dh-golang but I don't think we should do it
> here tbh, unless upstream changes their build system from meson to go
> (the current repo dir structure doesn't play well with dh-golang).
> 
> I don't plan to work on this anymore atm but thought I'd share our
> changes in case anyone find them useful.

I took your packaging, dropped one of the vendored packages having
updated it in Debian, and uploaded it to NEW.

The Git repository is now located here:
https://salsa.debian.org/debian/podman-toolbox

-- 
Cheers,
  Andrej

Bug#995878: O: gdigi -- utility to control DigiTech effect pedals

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: Ahmed Toulan 
Control: affects -1 src:gdigi

I intend to orphan the gdigi package.

The maintainer of the package, Ahmed, hasn’t had time to work on it
since 2013, and I’m also not interested in this package myself.

I have updated the package to the latest upstream snapshot, ran
lintian-brush on it, fixed a few minor issues and uploaded it with dgit.

The package description is:
 gdigi is a tool aimed to provide X-Edit functionality to Linux users
 .
 Supported devices:
* RP150
* RP155
* RP250
* RP255
* RP355
* RP500
* RP1000
* GNX3000
* GNX4K

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Control: tag -1 pending

Hi,

FYI I have uploaded shutter to NEW yesterday.

-- 
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hi,

On Sun, 29 Aug 2021, at 13:49, Michael Kogan wrote:
> Am Fr., 20. Aug. 2021 um 06:52 Uhr schrieb jiho lee :
>> Hi Andrej.
>> 
>> Is there anything else I need to support regarding shutter packaging?
>> 
>> There is a future society, but my future is not what others do.
>> Dept. of Information Science, Graduate School, Korea National Open University
> 
> Anything we can do from upstream to get this moving? We have now up to date 
> packages for Arch/Manjaro, Fedora, Gentoo, so Debian is the by far biggest 
> distro which hasn't packaged Shutter yet...

Thanks very much for your offer, but at the moment the only thing blocking it 
is me uploading the package :) The extra dependency is now in Debian, so I can 
proceed with uploading Shutter too before I go on my holiday.

-- 
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hi

On Tue, 17 Aug 2021, at 18:08, Michael Kogan wrote:
> logix2 has taken over the maintenance for the official Ubuntu PPA at 
> https://launchpad.net/~shutter/+archive/ubuntu/ppa/+packages?field.name_filter=_filter=published_filter=hirsute
>  recently.
> 
> I assume that the package names are valid for Debian as well, so the package 
> most probably could be reused for Debian with only minor modifications. 
> Here's a direct link to the actual Shutter package: 
> https://launchpad.net/~shutter/+archive/ubuntu/ppa/+sourcefiles/shutter/0.98-1~1ppa1~hirsute0/shutter_0.98-1~1ppa1~hirsute0.debian.tar.xz

Unfortunately, that packaging isn’t well-commented, so it’s not easy to verify 
what exactly is needed and what isn’t.
It would be much better if you as the upstream documented the exact 
dependencies and other requirement, preferably in some standard format e.g. 
(probably? I’m not a Perl expert) META.yml or something, or at least in the 
README file.

-- 
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hi Michael,

On Tue, 17 Aug 2021, at 12:22, Michael Kogan wrote:
> Thanks for your work on the Shutter package! I'm member of the Shutter team 
> (upstream), if there are any doubts or issues, please let me know here or 
> post a question at 
> https://github.com/shutter-project/shutter/issues/new/choose

It would be great if you could verify the list of dependencies in Jiho’s 
package (the control file).

Here’s the word diff compared to the dependencies of the old 0.94 version:

Depends:
[-imagemagick,-]
[- libfile-basedir-perl,-]{+gir1.2-appindicator3-0.1,+}
{+ libcarp-always-perl,+}
{+ libextutils-depends-perl,+}
libfile-copy-recursive-perl,
[-libfile-which-perl,-]
[- libglib-perl,-]
[- libgnome2-canvas-perl,-]
[- libgnome2-gconf-perl,-]
[- libgnome2-perl,-]
[- libgnome2-vfs-perl,-]
[- libgnome2-wnck-perl,-]
[- libgtk2-imageview-perl,-]
[- libgtk2-perl,-]
[- libgtk2-unique-perl,-]{+libgoocanvas2-perl,+}
{+ libgtk3-perl,+}
libimage-magick-perl,
[-libjson-perl,-]
[- libjson-xs-perl,-]
[- liblocale-gettext-perl,-]{+libjson-maybexs-perl,+}
libnet-dbus-perl,
[-libnet-dropbox-api-perl,-]{+libnet-oauth-perl,+}
{+ libnet-oauth2-perl,+}
{+ libnumber-bytes-human-perl,+}
{+ libpango-perl,+}
libpath-class-perl,
[- libproc-processtable-perl,-]
libproc-simple-perl,
[- librsvg2-common,-]
[- libsort-naturally-perl,-]
libwww-mechanize-perl,
[- libwww-perl,-]
[- libx11-protocol-other-perl,-]
[- libx11-protocol-perl,-]
[- libxml-simple-perl,-]
[- procps,-]
[- xdg-utils,-]
${misc:Depends},
${shlibs:Depends},
[-Recommends:-]
[- libgoo-canvas-perl,-]
[- libgtk2-appindicator-perl,-]
[- libnet-oauth-perl,-]
Suggests:
[-gnome-web-photo,-]{+libimage-exif-perl,+}
libimage-exiftool-perl,
[- libnet-dbus-glib-perl,-]
nautilus-sendto,

-- 
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hello,

On Tue, 17 Aug 2021, at 09:19, jiho lee wrote:
> I'd like to maintain the shutter package and related package.
> 
> In principle, shutter-team has exchanged opinions via e-mail and is 
> officially packaged and serviced in the distributed repository, and 
> shutter-team has created a related repository 
> (https://github.com/search5/shutter-deb), so please package it yourself and 
> upload it to the Debian.
> 
> I'm not a Debian maintainer, but I'd like to keep it for a while until 
> there's someone who can take care of the shutter.

Thanks for your interest in co-maintaining the package!

I’m merging some of your changes into the repository currently still in the 
attic (https://salsa.debian.org/perl-team/modules/attic/shutter), but I’m 
curious what is the best way to verify the necessary dependencies of the new 
code.

-- 
Cheers,
  Andrej

Bug#987884: ITP: git-autofixup -- Automatically fixup commits with related changes

[Andrej Shadura]

Hi,

On Sat, 1 May 2021, at 14:48, Daniel Gröber wrote:
> git-autofixup creates fixup commits from changes in the worktree. This
> can save the tedious work of amending fixes into the appropriate
> commits during codereview.
> 
> Changes to consider are parsed out of git-diff(1) and git-blame(1) is
> used to assign hunks to commits since the revision given on the
> commandline, which will typically represent a topic branch. Then it
> creates fixup commits to be used with git rebase --autosquash.
> 
> - There is another program called git-absorb which performs
>   essentially the same function as git-autofixup but is written in Rust
>   instead of Perl. Since Perl is much easier to package in Debian I went
>   for the latter ;)

Well, OTOH git-absorb already *is* in Debian :)

> - I plan to maintain this package myself, though I am looking for a
>   sponsor.

I can probably sponsor it. Or you can ask in pkg-perl (cc'ed).

-- 
Cheers,
  Andrej

Bug#987001: O: git-phab -- Git subcommand to integrate with Phabricator.

[Andrej Shadura]

Package: wnpp
Severity: normal
Control: affects -1 src:git-phab

I intend to orphan the git-phab package.

I no longer use this package, so I’m not the right person to maintain
it. It also seems to be abandoned upstream, who also seem to no longer
use Phabricator for code reviews.

The package description is:
 Tool to help out pushing Git changes into Phabricator Differential.

-- 
Cheers,
  Andrej

Bug#986937: ITA: po-debconf -- tool for managing templates file translations with gettext

[Andrej Shadura]

Control: reassign -1 !

Hi,

On Wed, 14 Apr 2021 15:54:00 +0200 Tobias Frost  wrote:
> Package: wnpp
> 
> The current maintainer of po-debconf, Herbert Parentes Fortes Neto 
> ,
> is apparently not active anymore.  Therefore, I orphan this package now.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
> 
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.

I intend to adopt this package.

Meanwhile, I’ve imported the complete history into Git here:
https://salsa.debian.org/debian/po-debconf

-- 
Cheers,
  Andrej

Bug#869534: ITP: ptpython -- Alternative Python Prompt

[Andrej Shadura]

Hi Daniel,

On Fri, 26 Feb 2021 08:25:24 +0100 Daniel Baumann
 wrote:
> retitle 869534  ITP: ptpython -- Alternative Python Prompt
> owner 869534 Daniel Baumann 
> thanks

I know this is my fault, but I prepared a package for ptpython not
having checked for an ITP in advance. I later found the ITP but decided
to push my work so that you can take bits from it and merge with
whatever you have:

https://salsa.debian.org/python-team/packages/ptpython

-- 
Cheers,
  Andrej

Bug#984462: RFH: open-build-service

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org, Andrew Lee (李健秋) 
, Debian Ruby Extras Maintainers 


Hi,

While I don’t work on the OBS package in Debian, I know about the state
of the package in Debian right now: the team, and most notably the main
maintainer, Andrew Lee, need help to maintain this package, as it
requires a lot of work due to a combination of Ruby / Ruby on Rails,
Perl and shell bits. Ruby parts specifically is a pain point, since
there’s a lot of gems this package depends on and updating one or
multiple of them can break OBS in ways the upstream didn’t think about.

The package has already missed Buster and Bullseye, and if the situation
doesn’t improve, it may result in a removal at some point.

Unfortunately, I lack necessary knowledge of the Ruby ecosystem to be
able to meaningfully help myself, but this package needs more people to
work on it, so if you can help, please consider doing so.

Thanks!

-- 
Cheers,
  Andrej

Bug#978694: RFP: python3-typer -- command line parsing library based on type hints

[Andrej Shadura]

Package: wnpp
Severity: wishlist

* Package name: python3-typer
  Version : 0.3.2
  Upstream Author : Sebastián Ramírez
* URL : https://github.com/tiangolo/typer
* License : MIT
  Programming Lang: Python 3.6+
  Description : command line parsing library based on type hints

Typer is a library for building CLI applications that users will love using and 
developers will love creating. Based on Python 3.6+ type hints.

The key features are:

 * Intuitive to write: Great editor support. Completion everywhere. Less time 
debugging. Designed to be easy to use and learn. Less time reading docs.
 * Easy to use: It's easy to use for the final users. Automatic help, and 
automatic completion for all shells.
 * Short: Minimize code duplication. Multiple features from each parameter 
declaration. Fewer bugs.
 * Start simple: The simplest example adds only 2 lines of code to your app: 1 
import, 1 function call.
 * Grow large: Grow in complexity as much as you want, create arbitrarily 
complex trees of commands and groups of subcommands, with options and arguments.

E.g. this code:

import typer

def main(name: str):
typer.echo(f"Hello {name}")

if __name__ == "__main__":
typer.run(main)

is enough to enable this:

$ python main.py --help

Usage: main.py [OPTIONS] NAME

Arguments:
  NAME  [required]

Options:
  --install-completion  Install completion for the current shell.
  --show-completion Show completion for the current shell, to copy it 
or customize the installation.
  --helpShow this message and exit.

P.S. I don’t have an immediate use for this, so I’m filing it as an RFP, but
I intend to package it some time soon if nobody beats me to it.

-- 
Cheers,
  Andrej

Bug#896910: O: libdigidoc -- DigiDoc digital signature library

[Andrej Shadura]

And yet another mail from me.

On Wed, 30 Dec 2020, at 09:14, Andrej Shadura wrote:
> On Wed, 30 Dec 2020, at 08:31, Vagrant Cascadian wrote:
> > I'd like to do a QA upload to fix a reproducible builds issue (#978064)
> > and other basic package maintenance as I'm able without disturbing the
> > package too much, but the above makes it a little unclear how to
> > proceed... I'd rather just use dgit than subscribe to another salsa
> > team.
> 
> Sure, please go ahead with dgit (--gbp iirc), I'll push to Salsa myself.

Actually, I also went ahead and added the debian group to the ACL of this 
repository only so you should be able to push too.

-- 
Cheers,
  Andrej

Bug#896910: O: libdigidoc -- DigiDoc digital signature library

[Andrej Shadura]

Hello again,

On Wed, 30 Dec 2020, at 08:31, Vagrant Cascadian wrote:
> On 2018-04-25, Andrej Shadura wrote:
> > I intend to orphan libdigidoc. This library is a part of a bigger software
> > suite for Estonian eID. My current eID is expiring this month, and since I
> > never used it for anything serious and probably don’t intend to, I won’t be
> > renewing it. Not being a user, maintaining it in Debian doesn’t seem right
> > or fair.
 
> The status of libdigidoc seems half-way a QA package, and half-way
> maintained by Andrej Shadura.



> Since it was orphaned, several uploads have been done, including a
> switch to using the eidas-team salsa repository. Previously dgit URLs
> were in Vcs-*.

A clarification:

libdigidoc is mostly needed to enable working with the legacy digitally-signed 
container format developed in Estonia, while libdigidocpp (not packaged yet) 
enables support for the Estonian flavour of the interoperable format.

Earlier this year I realised libdigidocpp is the only non-Java non-C# library 
for the format while also not being a monstrous suite of unrelated software, so 
I thought I probably should package at least those parts of the Estonian eID 
suite to enable working with eIDAS-compliant files — but libdigidoc is still 
needed for it, and its similar to the Slovak legacy "ZEP" digitally-signed 
container format so that I might be able to extend it to work with those files 
too.

When I find time to get back to those things, the package will be maintained 
under the eIDAS team (currently it’s just myself), but until that happened, 
it’s only halfway there since nothing currently depends on it yet.

-- 
Cheers,
  Andrej

Bug#896910: O: libdigidoc -- DigiDoc digital signature library

[Andrej Shadura]

On Wed, 30 Dec 2020, at 08:31, Vagrant Cascadian wrote:
> I'd like to do a QA upload to fix a reproducible builds issue (#978064)
> and other basic package maintenance as I'm able without disturbing the
> package too much, but the above makes it a little unclear how to
> proceed... I'd rather just use dgit than subscribe to another salsa
> team.

Sure, please go ahead with dgit (--gbp iirc), I'll push to Salsa myself.

-- 
Cheers,
  Andrej

Bug#977565: RFP: node-castv2 -- Chromecast CASTV2 protocol implementation

[Andrej Shadura]

Package: wnpp
Severity: wishlist

* Package name: node-castv2
  Version : 0.1.10
  Upstream Author : Thibaut Séguy, James Sigurðarson
* URL : https://github.com/thibauts/node-castv2
* License : Expat
  Programming Lang: JavaScript
  Description : Chromecast CASTV2 protocol implementation

An implementation of the Chromecast CASTV2 protocol

This module is an implementation of the Chromecast CASTV2 protocol over
TLS.

The module provides both a Client and a Server implementation of the
low-level protocol. The server is (sadly) pretty useless because device
authentication gets in the way for now (and maybe for good). The client
still allows you to connect and exchange messages with a Chromecast
dongle without any restriction.

This module is a dependency of a Chromecast protocol bridge for fx_cast,
an experimental Firefox casting extension.

Bug#977564: RFP: node-protobufjs -- pure JavaScript Protocol Buffers implementation

[Andrej Shadura]

Package: wnpp
Severity: wishlist

* Package name: node-protobufjs
  Version : 6.10.2
  Upstream Author : Daniel Wirtz
* URL : https://github.com/dcodeio/protobuf.js
* License : BSD 3-Clause
  Programming Lang: JavaScript
  Description : pure JavaScript Protocol Buffers implementation

protobuf.js is a pure JavaScript Protocol Buffers implementation
with TypeScript support for node.js and the browser.

It is a dependency of node-castv2, an implementation of the
Chromecast CASTV2 protocol.

Bug#403619: ITP: languagetool -- rule-based language checker' from 'RFP: languagetool -- rule-based language checker

[Andrej Shadura]

Hi again,

On Sun, 13 Dec 2020, at 10:03, Andrej Shadura wrote:
> I started working on it back then but I ran into a dependency on 
> opennlp-models, which come with no license. I tried to find a 
> workaround but I couldn’t find enough time for that.

Just to clarify: feel free to pick this up if you have time and energy for it :)

-- 
Cheers,
  Andrej

Bug#403619: ITP: languagetool -- rule-based language checker' from 'RFP: languagetool -- rule-based language checker

[Andrej Shadura]

Hi,

On Sun, 13 Dec 2020, at 00:54, Nicholas D Steeves wrote:
> On Sun, Dec 30, 2018 at 10:23:30AM +0100, Andrej Shadura wrote:
> > owner 403619 !
> > thanks
> 
> I noticed that you're the owner of this bug and am wondering if you
> plan to package languagetool in time for bullseye.  I for one would
> appreciate it! :-)

I started working on it back then but I ran into a dependency on 
opennlp-models, which come with no license. I tried to find a workaround but I 
couldn’t find enough time for that.

[1]: 
https://www.mail-archive.com/languagetool-devel@lists.sourceforge.net/msg05443.html
[2]: https://www.mail-archive.com/dev@opennlp.apache.org/msg02960.html

-- 
Cheers,
  Andrej

Bug#972850: ITP: soong -- Soong build system for Android

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: soong
  Version : 20201014 (17e97d9)
  Upstream Author : Google Inc et al
* URL : https://android.googlesource.com/platform/build/soong
* License : Apache-2.0
  Programming Lang: Go
  Description : Soong build system for Android

Soong is a build system for Android built on top of Blueprint, a
meta-build system. Soong is the replacement for the old Android
make-based build system. It replaces Android.mk files with Android.bp
files, which are JSON-like simple declarative descriptions of modules
to build.

This initial packaging is mostly to bring the relevant Go package into
Debian; the binary package will not initially be directly usable except
within a full Android build tree. At some point, a Debian-specific build
of Soong (dh_soong?) may appear allowing to build Debian packages of
Android tools directly with Soong.

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl+VMakUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJyuQf8C0iZzGGI6dIKS+g3y3VOQFYLdQzx
sfu2qP2coxMHFNoGEd0XZCvyxcprq8rKpL6kFgJ2plLbibuVWRKYIUqxbh1NVg35
ejqpll+QU3zhEoF5A1mW2DIqlfX6D6h//RDkP3LGvbK+82AFNjHFKCwGgoqPD/TD
s1R6g4mhGVC0ZUUCX6L2bEH+xKupUxU+nTbKTieaHKS2rs5G9RNBkulrDCdFETcn
vwByriR6m9tMFu1SAo3xCcOgJvv83KSY81zJnRLTCHuU705R5W8B9bh+AU0WhlMZ
JOsUSAjttXAdAojgVk2EAUUFaP9NTfLpUZ9+10vo/tySTKRX+cLMGwZh0g==
=Yr8Y
-END PGP SIGNATURE-

Bug#969246: RFP: coffeine -- CLI tool to keep your [device|mobile phone] from blanking or suspending

[Andrej Shadura]

On Sun, 30 Aug 2020 00:46:40 +0200 Sebastian Spaeth
 wrote:
> Package: coffein
> Version: 0.2; reported 2020-08-29
> Severity: wishlist
> 
> * Package name : coffeine
> Version : 0.2
> Upstream Author : Sebastian Spaeth 
> * URL : https://gitlab.com/sspaeth/coffeine/
> * License : GPL-3+
> Description : Keeps your computer awake at day (& night)
> 
> ... as long as your desktop supports the org.freedesktop.ScreenSaver 
> standard.
> 
> Just type 'coffeine YOURPROGRAMHERE' to prevent the screensaver from 
> interrupting your video session or your system from suspending while you 
> apt dist-upgrade it.

We already have caffeine, do we need another program for the same
purpose with a confusingly similar (but different) name?

https://packages.qa.debian.org/c/caffeine.html

-- 
Cheers,
  Andrej

Bug#968447: ITP: softether-vpn -- open-source cross-platform multi-protocol VPN program

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: softether-vpn
  Version : 4.34
  Upstream Author : Daiyuu Nobori, SoftEther Project at University of Tsukuba, 
and SoftEther Corporation
* URL : https://www.softether.org/
* License : Apache-2.0
  Programming Lang: C++
  Description : open-source cross-platform multi-protocol VPN program

SoftEther is an open-source cross-platform multi-protocol VPN program.

- - Supports all popular VPN protocols by the single VPN server:
  * SSL-VPN (HTTPS)
  * OpenVPN
  * IPsec
  * L2TP
  * MS-SSTP
  * L2TPv3
  * EtherIP
- - Free and open-source software.
- - Easy to establish both remote-access and site-to-site VPN.
- - SSL-VPN Tunneling on HTTPS to pass through NATs and firewalls.
- - Revolutionary VPN over ICMP and VPN over DNS features.
- - Resistance to highly-restricted firewall.
- - Ethernet-bridging (L2) and IP-routing (L3) over VPN.
- - Embedded dynamic-DNS and NAT-traversal so that no static nor
  fixed IP address is required.
- - AES 256-bit and RSA 4096-bit encryptions.
- - Sufficient security features such as logging and firewall inner
  VPN tunnel.
- - User authentication with RADIUS and NT domain controllers.
- - User authentication with X.509 client certificate.
- - Packet logging.
- - 1Gbps-class high-speed throughput performance with low memory and
  CPU usage.
- - Windows, Linux, Mac, Android, iPhone, iPad and Windows Phone are
  supported.
- - The OpenVPN clone function supports legacy OpenVPN clients.
- - IPv4 / IPv6 dual-stack.
- - The VPN server runs on Windows, Linux, FreeBSD, Solaris and Mac OS X.
- - Configure All settings on GUI.
- - Multi-languages (English, Japanese and Simplified-Chinese).



-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl837uoUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdLSCAgAscXAhLlhk2oX45F2OKS6SHfrAaIk
AnmXeckL+T6a8uRX3Hhxb6IJdJWqGaOe7xJJ+Txh6f7qo2sdzugF0J1GhWgaRcyC
BgJ9WnA4LC3E/NTizhqchoflXkT6FVhFu4F745E0NeT50hBABM6ks4BQgBPobg2n
fJSNN4WZ+E66uEwJVBx/bT67Z/X7aYx7A6Sd0V+pUsZWfqL5Nv/bi5GRUQFl5Tp1
/PUZE+mttxcxXi1bni/ppbuHpVpZP8BPHnIhSWL23Kuf/k/ZmdKFy3C3d+YsJQg9
S8fTYqgxl5qZFug7whMEBxBMSlsLEBjJa0GdFoPhOQx568VCqEtyUQ/JlQ==
=Vxyi
-END PGP SIGNATURE-

Bug#964785: ITP: shutter -- feature-rich screenshot program

[Andrej Shadura]

Hi Dominique,

On Sat, 11 Jul 2020, at 10:02, Dominique Dumont wrote:
> Hi Andrej
> 
> On vendredi 10 juillet 2020 15:22:45 CEST Andrej Shadura wrote:
> > I’m planning to reintroduce Shutter when the GTK 3 porting effort is
> > complete. Please see https://github.com/shutter-project/shutter/pull/284
> > for more details; please consider helping the upstream if you can.
 
> Feel free to re-use the old shutter package files that are currently in 
> debian-
> perl team attic:
> 
> https://salsa.debian.org/perl-team/modules/attic/shutter

Thanks for the pointer, I found that yesterday myself :)

-- 
Cheers,
  Andrej

Bug#964785: ITP: shutter -- feature-rich screenshot program

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

Hi everyone,

I’m planning to reintroduce Shutter when the GTK 3 porting effort is
complete. Please see https://github.com/shutter-project/shutter/pull/284
for more details; please consider helping the upstream if you can.

* Package name: shutter
  Version : NOT YET RELEASED
  Upstream Author : Mario Kemper, Alexey Sokolov and Shutter Team
* URL : http://shutter-project.org/
* License : GPL-3+
  Programming Lang: Perl
  Description : feature-rich screenshot program

 Shutter is a feature-rich screenshot program. You can take a
 screenshot of a specific area, window, your whole screen, or even of
 a website - apply different effects to it, draw on it to highlight
 points, and then upload to an image hosting site, all within one
 window.
 .
 Features:
* take a screenshot of your complete desktop, a rectangular area
  or capture a website
* take screenshot directly or with a specified delay time
* save the screenshots to a specified directory and name them in a
  convenient way (using special wild-cards)
* Shutter is fully integrated into the Gnome Desktop (TrayIcon etc.)
* generate thumbnails directly when you are taking a screenshot
  and set a size level in %
* Shutter session collection
  o keep track of all screenshots during session
  o copy screeners to clipboard
  o print screenshots
  o delete screenshots
  o rename your file
* upload your files directly to Image-Hosters
  (e.g. http://ubuntu-pics.de), retrieve all the needed links and
  share them with others
* edit your screenshots directly using the embedded drawing tool

-- 
Cheers,
  Andrej

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Andrej Shadura]

Hi

On Wed, 3 Jun 2020 at 11:50, Anthony Perkins  wrote:
> * Package name: ltunify
>   Version : 0.2
>   Upstream Author : Peter Wu 
> * URL : https://lekensteyn.nl/logitech-unifying.html
> * License : GPL-3.0+
>   Programming Lang: C
>   Description : Pair and manage Logitech devices that use the unifying 
> receiver
>
> Logitech wireless peripherals use a 'Unifying' receiver. This
> utility manages the receiver, allowing the user to pair new
> devices and remove unwanted ones.

I’m wondering in what ways is it better than Solaar already in Debian?
Do we need to have both?

https://pwr-solaar.github.io/Solaar/

> I require a sponsor, but intend to maintain the package myself.
>
> It had a release v0.2 roughly six years ago, and had a few
> additional patches in the following year but no new release. I
> will include a few of these patches as they fix bugs in the
> application.

-- 
Cheers,
  Andrej

Bug#916993: Bug#939721: ITP: intellij-community-idea -- Jars needed by kotlin built from intellij-community

[Andrej Shadura]

On Tue, 4 Feb 2020 10:17:23 +0100 Salvatore Bonaccorso
 wrote:
> On Sun, Sep 08, 2019 at 10:15:06AM +0400, Saif Abdul Cassim wrote:
> > Package: wnpp
> > Owner: Saif Abdul Cassim 
> > Severity: wishlist

> > IntelliJ IDEA Community Edition source code is available from
> > github.com/JetBrains/intellij-community by either cloning or downloading a
> > zip file (based on a branch) into . The default is the *master*
> > branch.

> > This package packages the jars that are needed from itnellij-community for
> > Kotlin 1.3.30 which I am working on.
> > 
> > I plan to maintain this package with the debian java maintainers team. This
> > package is needed for kotlin.

> There is as well the RFP bug as http://bugs.debian.org/747616, this is
> the same?

Thanks for the pointer. The source code is the same, but the packaging
effort is different. This ITP is focused on support libraries only, the
rest of IDEA still needs major work the other RFP is about.

-- 
Cheers,
  Andrej

Bug#747616: RFP: intellij-idea -- An integrated development environment for Java and other Java VM languages

[Andrej Shadura]

Control: block -1 916993

This RFP is about packaging a full-blown IDE, but it builds from the
same source as the intellij-community-idea source package we’re about to
upload. However, the current packaging effort is only focused on
packaging the support libraries IDEA comes with, which are reverse
dependencies of other packages such as the Kotlin compiler. When the
Kotlin compiler itself and Gradle 5 are in Debian, this RFP can be
revisited and addressed properly.

This should *not* be closed when #916993/#939721 is done.

-- 
Cheers,
  Andrej

Bug#960425: O: arcanist-clang-format-linter -- clang-format linter for Arcanist

[Andrej Shadura]

Package: wnpp
Severity: normal

I intend to orphan the arcanist-clang-format-linter package.

The package description is:
 This package allows to use clang-format as a linter for
 arcanist to enforce style over a C/C++/Objective-C codebase.

-- 
Cheers,
  Andrej

Bug#922154: ITP: libldac -- A lossy audio codec for Bluetooth connections

[Andrej Shadura]

On Fri, May 08, 2020 at 12:51:10PM +0200, Pali Rohár wrote:
> On Friday 08 May 2020 12:44:27 Andrej Shadura wrote:
> > Thanks but it's already done, on Salsa and in NEW :)

> Ou, I have not spotted it. Week ago it was not there.

True. I recalled I filed the ITP this week when I was thinking about
re-routing audio cables in my room or maybe getting rid of them altogether
:D

> I looked at it and I see that you are not using direct upstream sources.
> Is there any reason for it? I guess that packaging should be done from
> upstream project (in this case Android).

Well, it was a tiny bit easier, and also I was under an (incorrect)
impression libldac was a part of a monorepo, but in fact it is in a
separate Git repository.

I think I will update libldac to use the upstream source directly and also
use bits of your patch, thanks very much for it!

-- 
Cheers,
  Andrej

Bug#922154: ITP: libldac -- A lossy audio codec for Bluetooth connections

[Andrej Shadura]

Hi,

On Fri, 8 May 2020, 11:39 Pali Rohár,  wrote:

> Hello! I tried to prepare Debian packaging for this library. Diff for
> debian files is attached. There are two problems which I do not know how
> to easily fix:
>

Thanks but it's already done, on Salsa and in NEW :)

-- 
Cheers,
  Andrej

>

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 23:01, Yun Peng wrote:
>> It seemed there was some ambiguity on licensing from the links Andrej
>> posted. Do you know who (if anyone) is responsible for diffutils at
>> Google now? If Google holds copyright then it should be possible to get
>> clarification on that license.

> Although the code is hosted on Google Code Archive, I don't think Google
> owns this code because it's in our internal third_party directory. Also
> from the commit history
> ,
> I don't think any of the authors is Googler.
> This project looks like it is no longer under development, but on the
> Google Code Archive page
> , it states very
> clearly the license is Apache License 2.0.
If you read the original thread I linked, you’ll see the code is derived
from a different project and it was originally mixed ASL 1.1 and
LGPL-2.1 and was at some point relicensed by the j-d-u authors, which
they were not legally allowed to do.

This makes the code not acceptable in Debian.

I’m also very much against of packaging an obsolete and buggy old
version of the code when we already have the new one in Debian.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:39, Andrej Shadura wrote:
>>> On 06/05/2020 19:25, Andrej Shadura wrote:
>>>> I don’t think we need the original code since it’s much older and the
>>>> fork has seen quite some development. They are backwards-compatible
>>>> except that the Maven coordinates are different. Basically, we only need
>>>> to patch Bazel to use it.

> Java-diff-utils is based on the LGPL-2.1 code which IIRC was a direct
> port of GNU diff to Java, and the then-maintainer of j-d-u has slapped
> ASL on that code:

In other words, in my opinion the right approach would be to port Bazel
to the current j-d-u project, submit the patch upstream and thus reduce
the number of packages depending on the legacy j-d-u.

Uploading unmaintained legacy code with questionable licensing is a big
meh in my book.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:34, Andrej Shadura wrote:
> On 06/05/2020 19:31, Andrej Shadura wrote:
>> On 06/05/2020 19:25, Andrej Shadura wrote:
>>> I don’t think we need the original code since it’s much older and the
>>> fork has seen quite some development. They are backwards-compatible
>>> except that the Maven coordinates are different. Basically, we only need
>>> to patch Bazel to use it.
>>
>> Correction: they’re not fully compatible, but API difference is not big
>> and porting is quite straight-forward.
> 
> Right, I now remember one more reason why I chose the fork but not the
> original. There was a licensing issue around the diff algo
> implementation in the original. I don’t remember the details, but the
> fork has completely reimplemented it, thus working it around.

Java-diff-utils is based on the LGPL-2.1 code which IIRC was a direct
port of GNU diff to Java, and the then-maintainer of j-d-u has slapped
ASL on that code:

https://bugs.debian.org/845471#52

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:31, Andrej Shadura wrote:
> On 06/05/2020 19:25, Andrej Shadura wrote:
>> I don’t think we need the original code since it’s much older and the
>> fork has seen quite some development. They are backwards-compatible
>> except that the Maven coordinates are different. Basically, we only need
>> to patch Bazel to use it.
> 
> Correction: they’re not fully compatible, but API difference is not big
> and porting is quite straight-forward.

Right, I now remember one more reason why I chose the fork but not the
original. There was a licensing issue around the diff algo
implementation in the original. I don’t remember the details, but the
fork has completely reimplemented it, thus working it around.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On 06/05/2020 19:25, Andrej Shadura wrote:
> I don’t think we need the original code since it’s much older and the
> fork has seen quite some development. They are backwards-compatible
> except that the Maven coordinates are different. Basically, we only need
> to patch Bazel to use it.

Correction: they’re not fully compatible, but API difference is not big
and porting is quite straight-forward.

-- 
Cheers,
  Andrej

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On Wed, 6 May 2020 13:11:52 -0400 Olek Wojnar  wrote:
> On Wed, May 6, 2020 at 12:32 PM Sudip Mukherjee 
> wrote:
> 
> > On Wed, May 06, 2020 at 04:54:22PM +0100, Sudip Mukherjee wrote:
> >
> > > Taking the source from:
> > > https://code.google.com/archive/p/java-diff-utils/source/default/source
> > > the packaging was fairly simple and if noone has already done it I can
> > > finalize it and upload to mentors and change this to ITP at the same
> > time.
> >

> That would be great! It would be best to have someone from the Java Team
> review/sponsor but, if none of them are available, I am willing to do that.

> fwiw, I did a diff and its the same source in the linked jar and the
> > link I gave. Also, looking at java-diff-utils that Andrej mentioned, is
> > actually a fork from the google code.

> Thanks for doing that extra check and good to know! The fork (as well as
> the line vs character thing) would probably be good to mention in the
> package description so it's clear for everyone. I'd also consider adding
> the "google" at the front of the package name (or something else) to easily
> distinguish it from the one already in the repository and prevent confusion
> from users.

I don’t think we need the original code since it’s much older and the
fork has seen quite some development. They are backwards-compatible
except that the Maven coordinates are different. Basically, we only need
to patch Bazel to use it.

-- 
Cheers,
  Andrej

Bug#959834: RFP: diffutils-java -- Implementation of general operations with diff files

[Andrej Shadura]

On Tue, 05 May 2020 21:35:27 -0400 Olek Wojnar  wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: diffutils-java
>   Version : 1.3.0
>   Upstream Author : Dmitry Naumenko 
> * URL : 
> https://repo1.maven.org/maven2/com/googlecode/java-diff-utils/diffutils/1.3.0/diffutils-1.3.0-sources.jar
> * License : Apache 1.1
>   Programming Lang: Java
>   Description : Implementation of general operations with diff files

We already have this package in Debian, but a newer version of it:

https://packages.qa.debian.org/j/java-diff-utils.html

-- 
Cheers,
  Andrej

Bug#951551: ITP: httpx -- fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2

[Andrej Shadura]

On 04/05/2020 00:52, Sandro Tosi wrote:

On Thu, Apr 30, 2020 at 4:14 AM Andrej Shadura
 wrote:


Hi Sandro,

On 18/03/2020 19:55, Sandro Tosi wrote:

I’m glad to see you started to work on this. Is there anything I can
help with?\



I think i'm good, thanks for checking in.



Have you had time to work on this in the meantime? If not, maybe I can
take this ITP over? I need httpx for a project I work on, and I’d like
to use the packaged version but at the same time avoid duplicate effort.



please hold, i'll have it uploaded to NEW withing 15 days from today.


Thanks a lot, really looking forward to having it in Debian. By the way, 
there’s a new release planned in the coming days, you may want to pull 
it in while working on this.


--
Cheers,
  Andrej

Bug#951551: ITP: httpx -- fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2

[Andrej Shadura]

Hi Sandro,

On 18/03/2020 19:55, Sandro Tosi wrote:

I’m glad to see you started to work on this. Is there anything I can
help with?\



I think i'm good, thanks for checking in.


Have you had time to work on this in the meantime? If not, maybe I can 
take this ITP over? I need httpx for a project I work on, and I’d like 
to use the packaged version but at the same time avoid duplicate effort.


Thanks in advance.

--
Cheers,
  Andrej

Bug#959100: ITP: fractal -- Matrix.org messaging app for GNOME written in Rust

[Andrej Shadura]

Hi,

On Wed, 29 Apr 2020 at 17:49, Arnaud Ferraris  wrote:
> Le 29/04/2020 à 16:52, Andrej Shadura a écrit :
> > Hi Arnaud and Henry-Nicolas,
> >
> > Great! I haven’t noticed much happening over in the Rust repos or the
> > IRC channel, where are you co-ordinating? The dependency tree is quite
> > vast, so I suspect there will be enough work for all of us.
>
> We're discussing through a Matrix private chat for now, but we can move
> to something more public.
> We're also using a wiki[1] in salsa to keep track of the dependency tree
> and each crate's packaging status.
>
> [1] https://salsa.debian.org/a-wai/debcargo-conf/-/wikis/Home

It would be great if you used TODO.rst in debcargo-conf, which is the
place others co-ordinate packaging dependencies.

-- 
Cheers,
  Andrej

Bug#959100: ITP: fractal -- Matrix.org messaging app for GNOME written in Rust

[Andrej Shadura]

Hi Arnaud and Henry-Nicolas,

On Wed, 29 Apr 2020 at 15:23, Arnaud Ferraris  wrote:
> Le 29/04/2020 à 13:16, Andrej Shadura a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Andrej Shadura 
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > * Package name: fractal
> >   Version : 4.2.2
> >   Upstream Author : Daniel García Moreno and others
> > * URL : https://gitlab.gnome.org/GNOME/fractal
> > * License : GPL-3
> >   Programming Lang: Rust
> >   Description : Matrix.org messaging app for GNOME written in Rust
> >
> > Fractal is a GNOME chat app for the Matrix communication protocol.

> Cool!
>
> FYI, I've started working on Fractal's dependencies, along with
> Henry-Nicolas Tourneur, maybe we should synchronize on this?

Great! I haven’t noticed much happening over in the Rust repos or the
IRC channel, where are you co-ordinating? The dependency tree is quite
vast, so I suspect there will be enough work for all of us.

--
Cheers,
  Andrej

Bug#721192: ITP: uberwriter -- a simple markdown editor

[Andrej Shadura]

Hi,

On Mon, 27 Jan 2020 16:45:04 -0700 Nicholas D Steeves 
 wrote:

I started packaging uberwriter for a family member and am currently
about 75% done.  Seeing as there hasn't been any activity for five
years I don't think anyone will object.


How’s your progress? Could you put it somewhere on Salsa maybe?

Also please be aware UberWriter is now Apostrophe:

https://gitlab.gnome.org/somas/apostrophe/

--
Cheers,
  Andrej

Bug#959100: ITP: fractal -- Matrix.org messaging app for GNOME written in Rust

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: fractal
  Version : 4.2.2
  Upstream Author : Daniel García Moreno and others
* URL : https://gitlab.gnome.org/GNOME/fractal
* License : GPL-3
  Programming Lang: Rust
  Description : Matrix.org messaging app for GNOME written in Rust

Fractal is a GNOME chat app for the Matrix communication protocol.

The package will be co-maintained by the Debian Rust and Matrix teams.

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl6pYg8UHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdLjFgf+O8HQDfPTrjHyY0RGIcU46ZXlKAou
8ly0u+YE+hUMu4EoSPheUdhtd75xZgU9xeybXFv8HDntpq4F1DIb1wFfMhtsj9wp
rolglaC/sAVQYoVyCP5aXRkmXgTC//gw4geTvd8fuujLcDqppw4yx8xRGxz1sCQu
yPbldimFKXtIWqUSXAGpxByYG8sYKN3RKzupUUIB0dUufFuIChpTUj25SP9ztToC
TrQDPbgbjAPeJPfjWajoe3q6m2UrLdmGB3/fZMzTTqlMJPHmF9m3jz2mSXbiCJpx
DOuS1/YPzZIdF9fl5dDYWU9JtntcLpPx18aPcIiqclBcFCy6Ax4pKEUHtw==
=F6j6
-END PGP SIGNATURE-

Bug#958295: RFH: clipit -- lightweight GTK+ clipboard manager

[Andrej Shadura]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I request assistance with maintaining the clipit package.

The package was previously maintained by Dmitry Smirnov, who gave up
on it at some point; I attempted to take it over, but with upstream
not taking care of it, and unable to fix bugs, I switched to diodon[1]
myself, so I’m not using ClipIt anymore, and I cannot take it over
upstream, unfortunately; I have too many other things on my plate at
the moment.

Parcellite, from which ClipIt was forked, had had some life breathed
into it temporarily, and I believe the annoying UTF-8 support bug has
been fixed, but otherwise it’s been equally dead upstream for years[2].

Diodon seems to be the least buggy of the three, and it also supports
images, which neither ClipIt or Parcellite do. I’ve been using it for
about a year now, and so far I’ve not had any troubles with it.

In the more than half a year since I orphaned the package (#941081),
nobody volunteered to take this over but since I’m still set as the
maintainer in the currently uploaded release, I see that people are
still using it and there are more annoying bugs than just what I
observed.

My biggest complaint about ClipIt was that since the last upstream
release it became very unreliable: items sometimes don’t get copied into
the clipboard, sometimes wrong items get pasted, and also it somehow
mangles with the selection making it disappear immediately in some apps
like GNOME Terminal and LibreOffice.

Since the upstream developer disappeared a year ago, there’s been some
user activity on GitHub, but nobody seems to have fixed the most
annoying issues.

The best course of action now would be to take this package over
upstream and get it fixed, or at least get it fixed in Debian. A
lighter-weight alternative would be reverting it in Debian (sans the
icon changes I made) to the previous upstream version, which, while less
performant, was much more stable. Another way of fixing this would be
removing clipit completely and recommending users to switch over to
diodon; maybe also automatically migrate them over?

If you intend to take this package over, please please make sure that you
actually can get it sorted, it is not a trivial job, as I have painfully
learnt myself.

As I described in #909309, given all this, I’m not very motivated to do any
work myself since migrating to diodon have got my clipboard preserving
needs sorted, at least for now.

References:
 [0]: https://github.com/CristianHenzel/ClipIt
 [1]: https://packages.qa.debian.org/d/diodon.html
 [2]: https://github.com/rickyrockrat/parcellite/commits/master
 [3]: https://bugs.debian.org/941081
 [4]: https://bugs.debian.org/909309

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl6dZFgUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdKTGwgAreBK6k1Br7PZS3SOWnRQC11Q0+SM
0tC4kuyE8BMNcDyaLuyI+VboCCgX6+RiO5MP1cSGcgLC56ErMWUCs/2kCdrSd2T6
VkT1TPCv4Osoz9xX4ymQ68wmnkuhQRlEoPm8sVvMsqLX2g86e1lNKv1PaNCgso0V
Q6hcjoPZnKTdDnBvLpSAKOKTnpfotcgbdLsdbINP2tAM5HbXE139NBtDtxp+0D6T
3IaxoR+ScyQkC2y4+PPwZiMMGQwSbSPSMjctzgdr9CkU0WTVZ66x50RTEq660iQh
n9ruosgiJtTh30HW7mfs6iKV54BVb2rrJ9laURicaih7X7iNOOUQD34SAw==
=8lzZ
-END PGP SIGNATURE-

Bug#953964: ITP: python-strictyaml -- Strict, typed YAML parser for Python

[Andrej Shadura]

Hi James,

On Sun, 15 Mar 2020 at 09:36, Andrej Shadura  wrote:
> On Sun, 15 Mar 2020 at 06:47, James Tocknell  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: James Tocknell 
> >
> > * Package name: python-strictyaml
> >   Version : 1.0.6
> >   Upstream Author : Colm O'Connor 
> > * URL : https://hitchdev.com/strictyaml/
> > * License : MIT
> >   Programming Lang: Python
> >   Description : Strict, typed YAML parser for Python
> >
> > StrictYAML is a type-safe YAML parser that parses and validates a restricted
> > subset of the YAML specification.
> >
> > Priorities:
> >  - Beautiful API
> >  - Refusing to parse the ugly, hard to read and insecure features of YAML 
> > like
> >the Norway problem.
> >  - Strict validation of markup and straightforward type casting.
> >  - Clear, readable exceptions with code snippets and line numbers.
> >  - Acting as a near-drop in replacement for pyyaml, ruamel.yaml or poyo.
> >  - Ability to read in YAML, make changes and write it out again with 
> > comments
> >preserved.
> >  - Not speed, currently.
>
> Feel free to prod me when you get the packaging ready for review and
> sponsorship.

How’s your progress on this? Please be aware
https://salsa.debian.org/philpep-guest/strictyaml exists, you may want
to take that and slightly update it.

-- 
Cheers,
  Andrej

Bug#951551: ITP: httpx -- fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2

[Andrej Shadura]

Hi,

On Mon, 17 Feb 2020 20:47:33 -0500 Sandro Tosi  wrote:

* Package name: httpx
  Version : 0.11.1
  Upstream Author : Encode OSS
* URL : https://www.python-httpx.org/
* License : BSD
  Programming Lang: Python
  Description : fully featured HTTP client, with sync and async APIs, and 
support for both HTTP/1.1 and HTTP/2


I’m glad to see you started to work on this. Is there anything I can 
help with? I was going to package httpx myself, but found this ITP.


--
Cheers,
  Andrej

Bug#953964: ITP: python-strictyaml -- Strict, typed YAML parser for Python

[Andrej Shadura]

Hi,

On Sun, 15 Mar 2020 at 06:47, James Tocknell  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: James Tocknell 
>
> * Package name: python-strictyaml
>   Version : 1.0.6
>   Upstream Author : Colm O'Connor 
> * URL : https://hitchdev.com/strictyaml/
> * License : MIT
>   Programming Lang: Python
>   Description : Strict, typed YAML parser for Python
>
> StrictYAML is a type-safe YAML parser that parses and validates a restricted
> subset of the YAML specification.
>
> Priorities:
>  - Beautiful API
>  - Refusing to parse the ugly, hard to read and insecure features of YAML like
>the Norway problem.
>  - Strict validation of markup and straightforward type casting.
>  - Clear, readable exceptions with code snippets and line numbers.
>  - Acting as a near-drop in replacement for pyyaml, ruamel.yaml or poyo.
>  - Ability to read in YAML, make changes and write it out again with comments
>preserved.
>  - Not speed, currently.

Feel free to prod me when you get the packaging ready for review and
sponsorship.

-- 
Cheers,
  Andrej

Bug#953888: ITP: aioquic -- QUIC and HTTP/3 implementation in Python

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: aioquic
  Version : 0.8.6
  Upstream Author : Jeremy Lainé
* URL : https://github.com/aiortc/aioquic
* License : BSD-3-Clause
  Programming Lang: Python
  Description : QUIC and HTTP/3 implementation in Python

aioquic is a library for the QUIC network protocol in Python. It features
a minimal TLS 1.3 implementation, a QUIC stack and an HTTP/3 stack.

QUIC standardisation is not finalised yet, but aioquic closely tracks
the specification drafts and is regularly tested for interoperability
against other QUIC implementations.

Both the QUIC and the HTTP/3 APIs follow the “bring your own I/O”
pattern, leaving actual I/O operations to the API user.

Features:

 * QUIC stack conforming with draft-23
 * HTTP/3 stack conforming with draft-23
 * minimal TLS 1.3 implementation
 * IPv4 and IPv6 support
 * connection migration and NAT rebinding
 * logging TLS traffic secrets
 * logging QUIC events in QLOG format
 * HTTP/3 server push support

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl5s6BgUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJ06wf7BqHWnI7+F/nivULdPWAZPgVtqo6M
3AWN2Fsz5Is37MGfX92hhXR2VyAYTQXJWqyyntPip+pyFvgCKEodSJQTT2MBZX7R
PI6eoCJE4fB8jKX3nFd+YlrKuCpEPR/L4xwah3U86qP0cbJKkltdUW6vI67zQoKO
J+Bgg4vY4Ad2Pnz6i6cGsFDeNxl53Zv6PTwsaI3ZEfSY3WlfpqhHaI4vGCHg7/Us
cLm+Zqj2QXSIjhWhiPnuz1W+74zfuQccPfbnoK5Ug4xSICu81S+E7h2fOR37TG/r
omydDiF+7U18TAkOFsmqUPzmrUNuezcMLtVGEnyymWrkUUmxQVkS8+b/iw==
=jxQ8
-END PGP SIGNATURE-

Bug#953886: ITP: hypercorn -- ASGI Server based on Hyper libraries and inspired by Gunicorn

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: hypercorn
  Version : 0.9.2
  Upstream Author : Philip G Jones
* URL : https://gitlab.com/pgjones/hypercorn
* License : Expat
  Programming Lang: Python
  Description : ASGI Server based on Hyper libraries and inspired by 
Gunicorn

Hypercorn is an ASGI web server based on the sans-io hyper, h11, h2,
and wsproto libraries and inspired by Gunicorn. Hypercorn supports
HTTP/1, HTTP/2, WebSockets (over HTTP/1 and HTTP/2), ASGI/2, and ASGI/3
specifications. Hypercorn can utilise asyncio, uvloop, or trio worker
types.

Hypercorn can optionally serve the current draft of the HTTP/3
specification using the aioquic library.

Hypercorn was initially part of Quart before being separated out into
a standalone ASGI server. Hypercorn forked from version 0.5.0 of Quart.


-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl5s5PQUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdLEIQgAvXTxrHF4xAYib+rjLV6tmXTY1DdD
VdzFbabGNgyC1pNBE0/zpeIgiuGGCUvWa50ZldFlYzimKf7olkBZEW7oItiztX02
1jkWurFK3wg0m/XA8OUR0A5s1ucs0Exib75PWn6Tfnc7W5ku3pE3e/aaim4c7yuz
5OXQp3uxDsTGslWJF0MklFxRKXIz6U5AT8aLI4Zo9sT6VPP3wcS8s5g0h0BNiZ8w
vHEJjhSkyCo6xdEzdkoLsRMHcAlC53J3ugncgo7TkNvOz60LJe5JR//YGqoiBE+T
4xqa7A8sMqIedjuplvYr3/9QwnIq1VIqMAnFkRyyFhTALrTyxB5XQHzPiA==
=MQXe
-END PGP SIGNATURE-

Bug#953885: ITP: quart -- Python ASGI web microframework with the same API as Flask

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: quart
  Version : 0.11.3
  Upstream Author : Philip G Jones
* URL : https://gitlab.com/pgjones/quart
* License : Expat
  Programming Lang: Python
  Description : Python ASGI web microframework with the same API as Flask

Quart is a Python ASGI web microframework. It is intended to provide the
easiest way to use asyncio functionality in a web context, especially
with existing Flask apps. This is possible as the Quart API is a superset
of the Flask API.

Quart aims to be a complete web microframework, as it supports HTTP/1.1,
HTTP/2 and websockets. Quart is very extendable and has a number of
known extensions and works with many of the Flask extensions.

Quart supports the full ASGI 3.0 specification as well as the websocket
response and HTTP/2 server push extensions. For those of you familiar
with Flask, Quart extends the Flask API by adding support for:

 * HTTP/1.1 request streaming
 * Websockets
 * HTTP/2 server push


-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl5s40sUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdK0JAgAu0MSxBlvwGUQeA/u4iLO+Df4ohbj
trgcpPtUsFIcHngPHMv5cTej+p0E9mw5xIbVZsrQNp5LfVTC7YETmZP0ETAQVYu3
Gz92BOGFA4ccyBYY5PJmV7AwrHR4JtoS2HdxzSpraFVCwiCRH/6rkMWOCFlSgA6n
fOnCHPzLgEourYawJYLGQG+4bdx3HEI/dObDyydTa1JfIAJQ0Ugs65rzOZNYlrKK
xcutPCYxfaeVaTOshiJX8/+/lTfVieaEAlk6pJnoWwQ3rgSRVU/S4/mo/7FhNM5x
d1WiCD7uO4zAX5HMX4xFUxHIcaGwFzxtEelcKgkph82bAtQzzeWSvHdjbA==
=fIJW
-END PGP SIGNATURE-

Bug#950017: ITP: imx-code-signing-tool -- code signing tool for i.MX platform

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: imx-code-signing-tool
  Version : 3.3.0
  Upstream Author : NXP
* URL : https://www.nxp.com/pip/IMX_SW2
* License : BSD-3
  Programming Lang: C
  Description : code signing tool for i.MX platform

 This package provides a code signing tool for signing images
 for i.MX-based NXP processors using High Assurance Boot (HABv4)
 library in the internal boot ROM or the Advanced High Assurance
 Boot (AHAB) subsystem.
 .
 This package also provides a variety of support scripts.

Bug#948778: RFP: makisu -- unprivileged Docker image builder

[Andrej Shadura]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: makisu
  Version : 0.1.13
  Upstream Author : Uber
* URL : https://github.com/uber/makisu
* License : Apache 2.0
  Programming Lang: Go
  Description : unprivileged Docker image builder

Makisu is a fast and flexible Docker image build tool designed for
unprivileged containerized environments such as Mesos or Kubernetes.

Some highlights of Makisu:

 * Requires no elevated privileges or containerd/Docker daemon, making
   the build process portable.
 * Uses a distributed layer cache to improve performance across a build cluster.
 * Provides control over generated layers with a new optional keyword
   #!COMMIT, reducing the number of layers in images.
 * Is Docker compatible. Note, the Dockerfile parser in Makisu is
   opinionated in some scenarios.

Makisu has been in use at Uber since early 2018, building thousands
of images every day across 4 different languages. The motivation and
mechanism behind it are explained in https://eng.uber.com/makisu/.

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl4cOQgUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJeNAgApe84vPUnSL5JJHXOD18lRPm3SN45
3YacQVbFL/Srki+UyJCTfL59rkiD1mg7Q1Y7AfywXpc6k/NaISznrx9QRMEw3aU0
IHHfIFIGVLuUYphuVJ9szm2W191Dvg5ukQ5dxeS2SMn5wdq93/KoXQ0+fhC1QoD8
/wGoTQDQhIV+JVBU+eSyap1YnA97bMNgdUFyon4/p/XMZY5IDK+II09f9Z1za9OI
nP7UfV8vER+X6EzdF3cz2uAf3XtCgDqVaLvsIWA7eN+T2kcE3t618a40t3Xy7Cgw
AmgLAU/h3c1mYLyg5kdNbk8y+8CyWZLz76mv9mzQuS4kDiS5k6RA3SMBfQ==
=K4bE
-END PGP SIGNATURE-

Bug#948451: ITP: python-cliapp -- cliapp is a Python framework for Unix-like command line programs. It contains the typical stuff such programs need to do, such as parsing the command line for options

[Andrej Shadura]

Hi,

On Wed, 8 Jan 2020 at 20:37, JAIR REIS  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: JAIR REIS 
>
> * Package name: python-cliapp
>   Version : 1.20140719-1
>   Upstream Author : Lars Wirzenius 
> * URL : https://liw.fi/cliapp/
> * License : GPL
>   Programming Lang:  Python
>   Description : cliapp is a Python framework for Unix-like command line
> programs.
>
> It contains the typical stuff such programs need to do, such as parsing the
> command line for options, and iterating over input files.
>
>
> I'am begineer and I want to package for Debian Project. This is my first ITP.

https://packages.qa.debian.org/p/python-cliapp.html

-- 
Cheers,
  Andrej

Bug#948324: ITP: pymdown-extensions -- extension pack for Python Markdown

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: pymdown-extensions
  Version : 6.2.1
  Upstream Author : Isaac Muse
* URL : http://www.example.org/
* License : Expat
  Programming Lang: Python
  Description : extension pack for Python Markdown

PyMdown Extensions is a collection of extensions for Python Markdown.

 - arithmatex
 - b64
 - betterem
 - caret
 - critic
 - details
 - emoji
 - escapeall
 - extra
 - extrarawhtml
 - highlight
 - inlinehilite
 - keymap_db
 - keys
 - magiclink
 - mark
 - pathconverter
 - progressbar
 - slugs
 - smartsymbols
 - snippets
 - striphtml
 - superfences
 - tasklist
 - tilde

-- 
Cheers,
  Andrej

Bug#947727: O: herisvm -- machine learning tools for classification algorithms

[Andrej Shadura]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the herisvm package.

The package description is:
 herisvm project is a collection of simple tools implementing
 evaluation algorithms for classification (machine learning).
 In particular, heri-eval implements N-fold cross-validation
 where training and testing is run in parallel.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl4IwQgUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdId/Qf/Q6+ycKEd9Bcfg/rH10LMkGnU3G7M
GktW4Dyvb9lVenyzZj/iLw+TM1sixoomtClvyDn3//u5HDm/Bf49M8/Op0HqduOr
CRCV+hLjM02bCfPskAqGSckTGs2n+s7gSuBc69rv3/MnYYskTiIKIC3kkglHtyGP
bHwk1kM995YR0e1NRjsGi9KdTPd0EpB3s9WsHrIDvAjZbwcd+H9mUIfVKLOB3j8x
BnxXkE0uKlQq8Kcfv+lgb8nuidNP9QiQ/BYOx6vwmxD3y7qt+INsYY2yapDH7afk
WHjjhyO1xlkQlp9lNiiRTNyO+8tiAdVlBizodMJJme98hNJHqVmcJ8+U0A==
=bYMu
-END PGP SIGNATURE-

Bug#947406: ITP: qwertone -- simple music synthesizer

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: qwertone
  Version : 0.2.0
  Upstream Author : Andrii Zymohliad
* URL : https://gitlab.com/azymohliad/qwertone
* License : GPL-3
  Programming Lang: Rust
  Description : simple music synthesizer

Qwertone is a simple music synthesizer app.

It is basically a toy piano, but using a QWERTY keyboard for the input.

Bug#922565: ITA: tortoisehg -- Graphical tool for working with Mercurial

[Andrej Shadura]

Hi,

On Tue, 26 Nov 2019 at 15:47, Andrej Shadura  wrote:
> On Tue, 26 Nov 2019 at 15:39, peter green  wrote:
> > I notice after removal from unstable tortoisehg is back in new.
> >
> > However it seems that the package still build-depends on python 2 packages. 
> > In particular it depends on python-pyqt5.qsci which has been dropped by the 
> > qscintilla2 source package and decrufted from bullseye/sid.
> >
> > It seems to me that if this package is going to make a comeback it needs to 
> > migrate to python 3.
> >
> > (note: I am just a random dd who stubled across this package, the final 
> > descision of course rests with the ftpmasters and release team).
>
> The upstream package is being ported to Python 3 and reportedly works,
> but I understand we need to keep it in Python 2 until Mercurial also
> switches to Python 3 (also work in progress).

Oh, Gudjon pushed the update into unstable despite my request to hold
it off, thus making it impossible for TortoiseHg to come back.

-- 
Cheers,
  Andrej

Bug#922565: ITA: tortoisehg -- Graphical tool for working with Mercurial

[Andrej Shadura]

Hi,

On Tue, 26 Nov 2019 at 15:39, peter green  wrote:
> I notice after removal from unstable tortoisehg is back in new.
>
> However it seems that the package still build-depends on python 2 packages. 
> In particular it depends on python-pyqt5.qsci which has been dropped by the 
> qscintilla2 source package and decrufted from bullseye/sid.
>
> It seems to me that if this package is going to make a comeback it needs to 
> migrate to python 3.
>
> (note: I am just a random dd who stubled across this package, the final 
> descision of course rests with the ftpmasters and release team).

The upstream package is being ported to Python 3 and reportedly works,
but I understand we need to keep it in Python 2 until Mercurial also
switches to Python 3 (also work in progress).

-- 
Cheers,
  Andrej

Bug#944202: RFP: fonts-recursive -- Recursive Mono & Sans variable font family

[Andrej Shadura]

Package: wnpp
Severity: wishlist

* Package name: fonts-recursive
  Version : 1.022
  Upstream Author : Type
* URL : https://github.com/arrowtype/recursive
https://www.recursive.design/
* License : OFL-1.1
  Programming Lang: N/A
  Description : Recursive Mono & Sans variable font family

Recursive Mono & Sans is a variable type family built for better code &
UI. It is inspired by casual script signpainting, but designed primarily
to meet the needs of programming environments and application interfaces.

In programming, “recursion” is when a function calls itself, using its
own output as an input to yield powerful results. Recursive Mono was used
as a tool to help build itself: it was used to write Python scripts to
automate type production work and to generate specimen images, and it was
used in HTML, CSS, and JS to create web-based proofs & prototypes. Through
this active usage, Recursive Mono was crafted to be both fun to look at
as well as deeply useful for all-day work.

Recursive Sans borrows glyphs from its parent mono but adjusts the
widths of many key glyphs for comfortable readability. Its metrics are
superplexed – every style takes up the exact same horizontal space,
across all styles. In this 3-axis variable font, this allows for fluid
transitions between weight, slant, and “expression” (casual to strict
letterforms), all without text shifts or layout reflow. Not only does
this allow for new interactive possibilities in UI, but it also makes
for a uniquely fun typesetting experience.

Bug#943722: RFP: ciasdis -- a reverse engineering assembler

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Albert van der Horst 

-- Forwarded message -
From: Albert van der Horst 
Date: Mon, 28 Oct 2019 at 16:05
Subject: No Intent To Package : ciasdis a reverse engineering assembler.
To: Debian Mentors 


 From "control"

The package ciasdis contains an i86 assembler-disassembler
  combination that allows to reassemble to a byte-for-byte
  same binary. This is useful for modifying programs where
  the source was lost, analysing viruses, etc. and general
  curiosity. Knowledge about a binary can be build up
  automatically, using scripts, or interactively and can be
  stored for continued use in .cul files.
  .
"

Release 2.0.0 sports a large cleanup, notably it can be compiled on
newer 64 bits Forth compilers.

One of the examples is reversing a linux elf32 program, with
a crawler that extracts labels from the binary itself (not
from a section with debugging labels) and detects hundreds
of boundaries between text code and 32 bits data.

I have no intent to package it myself. However if anybody thinks
this package is valuable enough to do it, I will lend full
  cooperation.
As mentionned in the release notes
 make install
will basically generate a directory tree such as present in a
.deb file. Let's say I've done some prepratory work.

Groetjes Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst



-- 
Cheers,
  Andrej

Bug#943596: ITP: wget2 -- file and recursive website downloader

[Andrej Shadura]

Hi,

On Sun, 27 Oct 2019 at 08:14, Hideki Yamane  wrote:
> * Package name: wget2
>   Version : 1.99.2
>   Upstream Author : Tim Rühsen *tim.ruehsen [at] gmx.de*
> * URL : https://gitlab.com/gnuwget/wget2
> * License : GPL-3+, LGPL-3+
>   Programming Lang: C
>   Description : file and recursive website downloader

You may have missed this: https://packages.qa.debian.org/w/wget2.html

-- 
Cheers,
  Andrej

Bug#943382: RFP: karapulse -- Linux karaoke player

[Andrej Shadura]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: karapulse
  Version : 0.1.3
  Upstream Author : Guillaume Desmottes 
* URL : https://gitlab.freedesktop.org/gdesmott/karapulse
* License : GPL-3+
  Programming Lang: Rust
  Description : Linux karaoke player

Karapulse is a Linux karaoke player supporting CDG/MP3 as well as video
files. It provides a self-served web application that singers can use
with their phone to search for and queue their favorite songs.

Features


 * Support CDG/MP3; automatically match .mp3 and .cdg files if they
   have the same basename
 * Support all video formats.
 * Smart songs queueing algorithm ensuring a fair turn distribution
   among singers.
 * Built-in web mobile friendly client usable on desktop as well.
 * Full remote control, once setup no need for mouse or keyboard.
 * Free Software (GPLv3).
 * Written in Rust using GStreamer.

-BEGIN PGP SIGNATURE-

iJUEARYIAD0WIQT/pgwAncVK7KA57JwlJunrgoqPNQUCXbFFFB8cYW5kcmV3LnNo
YWR1cmFAY29sbGFib3JhLmNvLnVrAAoJECUm6euCio81NjsBAI4siqBR5dv6UL4R
szS+nuaq4CjMKFJnvouV2wCaOnrsAP43f0Pxx9yUqpaWkgEMv5a5zLpiEm7n7s2S
FnoQU/CUBQ==
=f6gX
-END PGP SIGNATURE-

Bug#941081: O: clipit -- lightweight GTK+ clipboard manager

[Andrej Shadura]

Package: wnpp
Severity: normal

I intend to orphan the clipit package. The package was previously
maintained by Dmitry Smirnov, who gave up on it at some point; I
attempted to take it over, but with upstream not taking care of it, and
unable to fix bugs, I switched to diodon[1] myself, so I’m not using
ClipIt anymore, and I cannot take it over upstream, unfortunately; I
have too many other things on my plate at the moment.

Parcellite, from which ClipIt was forked, had had some life breathed
into it temporarily, and I believe the annoying UTF-8 support bug has
been fixed, but otherwise it’s been equally dead upstream for years[2].

Diodon hasn’t seen any upstream development recently either, but at
least it seems to be the least buggy of the three, and it also supports
images, which both ClipIt and Parcellite don’t, so I’m sticking with it
for now.

If you intend to take this package over, please please make sure that you
actually can get it sorted, it is not a trivial job, as I have painfully
learnt myself.

The package description is:
 Clipboard manager with features such as:
  * Save history of your last copied items
  * Search through the history
  * Global hotkeys for most used functions
  * Execute actions with clipboard items
  * Exclude specific items from history
 .
 ClipIt was forked[0] from Parcellite and adds many bugfixes and features to the
 project.

References:
 [0]: https://github.com/CristianHenzel/ClipIt
 [1]: https://packages.qa.debian.org/d/diodon.html
 [2]: https://github.com/rickyrockrat/parcellite/commits/master

-- 
Cheers,
  Andrej

Bug#677174: RFA: python-minimock -- simple library for Python mock objects

[Andrej Shadura]

Hi,

I have uploaded a new upstream version and moved the package under the
Debian Python Modules Team, but nevertheless it needs a real maintainer
within or outside of the team, since I cannot commit to keep it up to
date as I don’t use it myself.

Please don’t close this bug unless you’re the person who is going to
really maintain the package.

Thanks.

-- 
Cheers,
  Andrej

Bug#932003: ITP: mypyc -- Mypy to Python C Extension Compile

[Andrej Shadura]

On 11/09/2019 16:00, Michael Crusoe wrote:
> Thanks Andrej!
> 
> I recently learned that mypyc is being rolled into the main mypy package
> upstream, so I'm holding off for the next release of mypy

Thanks for letting me know. When that happens, ping me if you need a
review or something.

Meanwhile, I have prepared a merge request to provide better manpages
for mypy: https://salsa.debian.org/med-team/mypy/merge_requests/1

Please consider to merge it if you’re not unhappy with the way I do it :)

-- 
Cheers,
  Andrej

Bug#932003: ITP: mypyc -- Mypy to Python C Extension Compile

[Andrej Shadura]

Hi,

On Sat, 13 Jul 2019 18:29:45 +0200 "Michael R. Crusoe"
 wrote:
> Package: wnpp
> Severity: wishlist
> 
> Subject: ITP: mypyc -- Mypy to Python C Extension Compile
> Package: wnpp
> Owner: Michael R. Crusoe 
> Severity: wishlist
> 
> * Package name: mypyc
>   Version : 0.0.git.20190713T1002.833151a+ds1
>   Upstream Author : Copyright: © 2017-2018 Jukka Lehtosalo and contributors
> * URL : http://www.mypy-lang.org/
> * License : Expat
>   Programming Lang: C
>   Description : Mypy to Python C Extension Compile
>  *Mypyc is (mostly) not yet useful for general Python development.*
>  .
>  Mypyc is a compiler that compiles mypy-annotated, statically typed
>  Python modules into CPython C extensions. Currently our primary focus
>  is on making mypy faster through compilation -- the default mypy wheels
>  are compiled with mypyc.  Compiled mypy is about 4x faster than
>  without compilation.
>  .
>  Mypyc compiles what is essentially a Python language variant using "strict"
>  semantics. This means (among some other things):
>  .
>   * Most type annotations are enforced at runtime (raising ``TypeError`` on
> mismatch)
>  .
>   * Classes are compiled into extension classes without ``__dict__``
> (much, but not quite, like if they used ``__slots__``)
>  .
>   * Monkey patching doesn't work
>  .
>   * Instance attributes won't fall back to class attributes if undefined
>  .
>   * Metaclasses not supported
>  .
>   * Also there are still a bunch of bad bugs and unsupported features :)
>  .
>  Compiled modules can import arbitrary Python modules, and compiled modules
>  can be used from other Python modules.  Typically mypyc is used to only
>  compile modules that contain performance bottlenecks.
>  .
>  You can run compiled modules also as normal, interpreted Python
>  modules, since mypyc targets valid Python code. This means that
>  all Python developer tools and debuggers can be used.
>  .
>  This package provides the command-line interface.
> 
> Remark: This package is maintained by Debian Med Packaging Team at
>https://salsa.debian.org/med-team/mypy

I’m going to review this; if you need a sponsor, I can do, just let me know.

-- 
Cheers,
  Andrej

Bug#939228: O: paexec -- execute tasks in parallel

[Andrej Shadura]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the paexec package.

The package description is:
 paexec is a tool to execute tasks in parallel.
 .
 paexec reads tasks from the standard input and distributes
 them over a number of nodes using a specified transport
 protocol.
 paexec is a tool to execute tasks in parallel.
 .
 paexec reads tasks from the standard input and distributes
 them over a number of nodes using a specified transport
 protocol.
 paexec is a tool to execute tasks in parallel.
 .
 paexec reads tasks from the standard input and distributes
 them over a number of nodes using a specified transport
 protocol.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl1tAYEUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdK9swgAiS7qfZAacRDUTfhMMW8Kg9pM+DvM
t4849vfW4pTGxLdB3AhZydRgsH2l8uP7W3x8kimKK3Wq5AXdAMZ/pBDG4sR1DH7Y
FJIyKvStjOCyGgZC3mMd6nQi9stTBzM7iQ4iJdu4lt3xK/O3ga4VRSLGbjIiMlo/
xXYelNYSN6g+3ROEtk1wFbZ9opAUZFQ94HAUGw3N387rAD24ZDwIQuYViBUWFArZ
ot8SGjdu67ed2WdUCLk9qyBMYa7qavEQDfKhMMw5ePmS9rASQNvDwHd9miy8ZdBf
lyumSEWJ+24QnOhqtYAw+5UM5X7DNyevIP0KdiJvhd5q4GzL+Q2jaekiCg==
=Pn/t
-END PGP SIGNATURE-

Bug#933735: ITP: drawing -- drawing application for GNOME

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: drawing
  Version : 0.4.2
  Upstream Author : Romain F.T.
* URL : https://maoschanz.github.io/drawing/
* License : GPL-3
  Programming Lang: Python
  Description : drawing application for GNOME

This application is a basic image editor, similar to Microsoft Paint, but 
aiming at the GNOME desktop.