Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Nilesh Patra]

On Thu, Jul 11, 2024 at 06:06:21PM +0200, Jonas Smedegaard wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-de...@lists.debian.org, build-common team 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: dh-rust

I would be happy if this makes it to the archive, though. Would be easier to
have a dh for rust which would be specifically useful to build packages that are
not just crates, but instead use multiple language including but not limited to
rust.

As an addendum, also gives freedom to maintain packages outside of the giant git
repo of crates, without having to embed this code in every such outside-of-team
maintained package.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1075841: ITP: golang-sourcehut-rockorager-vaxis --

[Nilesh Patra]

On Sun, Jul 07, 2024 at 09:38:00AM -0300, Guilherme Puida Moreira wrote:
> FYI, there's already an ITP open for vaxis (#1064818).

I know. FYI, I had merged both yesterday.


signature.asc
Description: PGP signature

Bug#1075841: ITP: golang-sourcehut-rockorager-vaxis --

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-sourcehut-rockorager-vaxis
  Version : 0.9.2-1
  Upstream Author : Tim Culverhouse 
* URL : https://git.sr.ht/~rockorager/vaxis
* License : Apache-2.0
  Programming Lang: Go
  Description : Terminal User Interface (TUI) library for go

 Vaxis is a Terminal User Interface (TUI) library for go. Vaxis supports
 modern terminal features, such as styled underlines and graphics. A
 widgets package is provided with some useful widgets.
 .
 Vaxis is blazingly fast at rendering. It might not be as fast or
 efficient as notcurses, but significant profiling has been done to
 reduce all render bottlenecks while still maintaining the feature-set.
 .
 Vaxis does not use terminfo. Support for features is detected
 through terminal queries. Vaxis assumes xterm-style escape codes
 everywhere else.


signature.asc
Description: PGP signature

Bug#1073802: ITP: oras -- OCI registry client - managing content like artifacts, images, packages

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: oras
  Version : 1.2.0-1
  Upstream Author : OCI Registry As Storage (ORAS)
* URL : https://github.com/oras-project/oras
* License : Apache-2.0
  Programming Lang: Go
  Description : OCI registry cli tool managing content like artifacts, 
images, packages
 ORAS works similarly to tools you may already be familiar with, such as
 docker. It allows you to push (upload) and pull (download) things to and
 from an OCI Registry, and also handles login (authentication) and token
 flow (authorization). What ORAS does differently is shift the focus from
 container images to other types of artifacts.
 .
 ORAS is the de facto tool for working with OCI Artifacts. It treats
 media types as a critical piece of the puzzle. Container images are
 never assumed to be the artifact in question.

Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux

[Nilesh Patra]

On Fri, May 17, 2024 at 08:52:00PM +0530, Prasanna Venkadesh wrote:
> 
> 
> On 15 May 2024 12:33:49 am IST, Nilesh Patra  wrote:
> >On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote:
> >>It seems, there is no packaging team available yet for Nim lang.
> >>I am not looking for co-maintainers, it's not complex.
> >
> >There does exist a nim team.
> >
> > https://salsa.debian.org/nim-team
> 
> Oh! I couldn't find the team in this wiki https://wiki.debian.org/Teams
> 
> In that case, I would like the package to be managed under the team. I also 
> notice that the package names for libraries follow nim-* pattern.
> 
> How about hybrids, when its both a CLI app & a library?

I suppose you need to name a package in a way that has more weight. Is it more
likely to be used by end users as a library or application? Name the source
package based on what makes more sense. As for battinfo, it makes more sense to
have an application name (battinfo instead of nim-battinfo).

> 
> What are my next steps?

You could contact the owners of nim team to grant you access to the salsa
namespace. If there's too much delay/you are in a hurry, you could use another
namespace for now.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux

[Nilesh Patra]

On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote:
>It seems, there is no packaging team available yet for Nim lang.
>I am not looking for co-maintainers, it's not complex.

There does exist a nim team.

https://salsa.debian.org/nim-team

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1065325: morph's abandoned packages (list)

[Nilesh Patra]

On Sat, May 11, 2024 at 11:54:29PM +0200, Alexandre Detiste wrote:
> Yes do please.

i finished migrating to dh13 and pushed to salsa

> Le sam. 11 mai 2024 à 20:51, Nilesh Patra  a écrit :
> >
> > Quoting Alexandre Detiste :
> > >  I would pick-up matplotlib I guess, I have some special connection to it,
> > >  It was one the packages that enabled me to escape
> > >  my horrible SAS-Insitute powered previous job/life.
> > >
> > >  It's a big one.
> > >
> > >  Help is appreciated, I already cherry picked some commits from Ciel's PR.
> >
> > Would you consider to add me in as an Uploader (co-maintainer) alongside 
> > you?
> >
> > I am a Debian Developer.
> >
> > Best,
> > Nilesh
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1065325: morph's abandoned packages (list)

[Nilesh Patra]

Quoting Alexandre Detiste :
>  I would pick-up matplotlib I guess, I have some special connection to it,
>  It was one the packages that enabled me to escape
>  my horrible SAS-Insitute powered previous job/life.
>  
>  It's a big one.
>  
>  Help is appreciated, I already cherry picked some commits from Ciel's PR.

Would you consider to add me in as an Uploader (co-maintainer) alongside you?

I am a Debian Developer.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Nilesh Patra]

On Mon, Apr 08, 2024 at 08:59:26AM +0300, Andrius Merkys wrote:
> On 2024-04-07 15:28, Nilesh Patra wrote:
> > Assistance required with maintaining the singularity-container package.
> 
> I am not offering help with singularity-container, but do you by any chance
> know why apptainer is not packaged for Debian? I cannot find a wnpp bug.

I am lazy to find references right now, but you should be able to find it in
debian-hpc and debian-devel archives. If I don't miss anything this was the
sequence of events:

1) While updating singularity-container, Andreas created a repo for apptainer on
salsa.
2) The goal at that time was to get a mobility compute (either apptainer or
singularity) up and running
3) singularity and apptainer codebases are in sync so as per my understanding
there's no real point in having *both* - here's a brief discussion about it[1]

My opinion: It does not make a lot of sense to package apptainer as well.
Although the latter is "community" maintained, the codebases for
sylabs/singularity and apptainer are in close sync at most times which also
means they keep inheriting CVEs from each other too.

As a result one may not be able to maintain apptainer well in stable release
either unless they have:
a) Good/Great go programming skills
b) ability to deal with CVEs and backports

I'd like to just link to a similar discussion thread about the same rather than
repeating the points[2] and here's what upstream says[3].

What do you think?

[1]: https://lists.debian.org/debian-hpc/2022/08/msg00021.html
[2]: https://lists.debian.org/debian-devel/2023/01/msg00078.html
[3]: https://lists.debian.org/debian-devel/2023/01/msg00080.html

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Nilesh Patra]

Package: wnpp
Severity: normal
X-Debbugs-Cc: singularity-contai...@packages.debian.org, 
debian-de...@lists.debian.org, o...@debian.org, me...@dogguy.org
Control: affects -1 + src:singularity-container

Assistance required with maintaining the singularity-container package.

I am not the uploader/maintainer of this package, however I am the only
one who has been taking care of it via team uploads for more than 2 years
and all other uploaders are MIA. Few of them asked me to remove myself from
uploaders field, which I have done. However, I don't consider the package
well-maintained w/o me doing the work.
It is also stalled from migrating to stable because maintaining it there
requires backporting and testing CVE fixes and I don't have the bandwidth
to do that work, which is the reason for #1029669.

With my available time, it is unlikely that I will be maintaining it timely
or at all.

Any help for maintaining it would be great.

The package description is:
 Mobility of Compute encapsulates the development to compute model
 where developers can work in an environment of their choosing and
 creation and when the developer needs additional compute resources,
 this environment can easily be copied and executed on other platforms.
 Additionally as the primary use case for Singularity is targeted
 towards computational portability, many of the barriers to entry of
 other container solutions do not apply to Singularity making it an
 ideal solution for users (both computational and non-computational)
 and HPC centers.


signature.asc
Description: PGP signature

Bug#1065237: O: astroidmail -- graphical notmuch email client

[Nilesh Patra]

Hi Daniel, Jonas,

Jonas Smedegaard wrote on Sat, 02 Mar 2024 08:59:58 +0100:
>  Quoting Sandro Tosi (2024-03-02 07:48:46)
> > Package: wnpp
> > Severity: normal
> > X-Debbugs-Cc: astroidm...@packages.debian.org, mo...@debian.org
> > Control: affects -1 + src:astroidmail
> > 
> > I intend to orphan the astroidmail package.
> > 
> > The package description is:
> >  Astroid is a lightweight and fast Mail User Agent that provides a
> >  graphical interface to searching, display and composing email,
> >  organized in thread and tags. Astorid uses the notmuch backend for
> >  blazingly fast searches through tons of email. Astroid searches,
> >  displays and compose emails - and rely on other programs for fetching,
> >  syncing and sending email.
>  
>  Hi Sandro,
>  
>  I don't quite follow what is going in here:
>  
>  It seems that you are orphaning a package maintained by someone else
>  than yourself, out of the blue, without explaining why and without
>  prior coordination with those maintaining the package?

I am very confused with this bug report as well. Meanwhile, Daniel seems to have
taken ownership of this bug and intends to maintain this and a few other 
packages
in the python team[1].

Jonas, are you actually willing to transfer the ownership?
In any case, please comment/communicate w/ Daniel before an upload happens 
leading to frustration
on both sides.

[1]: https://lists.debian.org/debian-python/2024/03/msg00033.html

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1064207: ITP: golang-sourcehut-rjarry-go-opt -- Parse command line arguments based on tag annotations on struct fields (library)

[Nilesh Patra]

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

* Package name: golang-sourcehut-rjarry-go-opt
  Version : 1.4.0
  Upstream Contact: Robin Jarry
* URL : https://git.sr.ht/~rjarry/go-opt
* License : Expat
  Programming Lang: Go
  Description : Parse command line arguments based on tag annotations on 
struct fields (library)
 
 This is a library to parse command line arguments based on tag
 annotations on struct fields. It came as a spin-off from aerc to deal
 with its internal commands.
 .
 This project is a scaled down version of https://github.com/alexflint/go-
 arg with different usage patterns in mind: command parsing and argument
 completion for internal application commands.

Bug#1063626: RFP: rust-adblock -- adblock-rust is the engine powering Brave's native adblocker, available as a library for anyone to use

[Nilesh Patra]

Package: wnpp
Severity: wishlist

* Package name: rust-adblock
  Version : 0.8.6
  Upstream Contact: Andrius Aucinas
* URL : https://crates.io/crates/adblock
* License : MPL-2.0
  Programming Lang: Rust
  Description : adblock-rust is the engine powering Brave's native 
adblocker, available as a library for anyone to use

  adblock-rust is the engine powering Brave's native adblocker, available as a 
library for anyone to use. It features:
  .
  Network blocking
  Cosmetic filtering
  Resource replacements
  Hosts syntax
  uBlock Origin syntax extensions
  iOS content-blocking syntax conversion
  Compiling to native code or WASM
  Rust bindings (crates)
  JS bindings (npm)
  Community-maintained Python bindings (pypi)
  High performance!

This is needed for angelfish, and also as a generally useful lib for adblocks.

Bug#1063612: ITP: corrosion -- Tool for integrating rust with an existing CMake project

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, nil...@debian.org

* Package name: corrosion
  Version : 0.4.7
  Upstream Contact: Andrew Gaspar
* URL : https://github.com/corrosion-rs/corrosion
* License : MIT
  Programming Lang: C++
  Description : Tool for integrating rust with an existing CMake project

  Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust
  into an existing CMake project.
  .
  Corrosion can automatically import executables, static libraries,
  and dynamic libraries from a workspace or package manifest
  (Cargo.toml file).

Needed for angelfish to manage it easily. This will be maintained in the debian
namespace.

Bug#1032659: ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.

[Nilesh Patra]

On Thu, Feb 01, 2024 at 11:17:58AM +, Christopher Obbard wrote:
> @Go Team, Can I have maintainer access to
> https://salsa.debian.org/go-team/packages/golang-github-go-task-slim-sprig ?
> Currently I am just developer on that repo, it'd be great to get full access
> so I can modify CI setting etc.

Done.


signature.asc
Description: PGP signature

Bug#1059860: ITP: golang-github-quic-go-quic-go -- A QUIC implementation in pure go

[Nilesh Patra]

On Tue, Jan 02, 2024 at 03:24:29PM +0100, Félix Sipma wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Félix Sipma 
> 
> * Package name: golang-github-quic-go-quic-go
>   Version : 0.40.0-1
>   Upstream Author : 
> * URL : https://github.com/quic-go/quic-go
> * License : Expat
>   Programming Lang: Go
>   Description : A QUIC implementation in pure go
> 
>  A QUIC implementation in pure Go
> 
> 
> Needed by newer versions of Syncthing.

There's already golang-github-lucas-clemente-quic-go-dev which seems to have
been renamed to quic-go/quic-go. Maybe this could add a provides to the new
package?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061568: ITP: source-map-js -- Generates and consumes source maps

[Nilesh Patra]

Hey,

On Fri, Jan 26, 2024 at 10:07:58PM +0530, Kalyani Kenekar wrote:
> Package: wnpp  
> Severity: wishlist
> Owner: Kalyani Kenekar 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: source-map-js
>   Version : 1.0.2
>   Upstream Author : Valentin Semirulnik 
> * URL : https://github.com/7rulnik/source-map-js
> * License : BSD-3clause 
>   Programming Lang: Javascript
>   Description : Generates and consumes source maps
> 
> The source-map-js package is a fork of source-map which includes some
> additional optimizations.

This is already provided by node-postcss

| $ apt show node-postcss 2>/dev/null | grep Provides
| Provides: node-colorette (= 2.0.20), node-line-column (= 1.0.2), node-nanoid 
(= 4.0.2), node-source-map-js (= 1.0.2)

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055192: RFS: golang-github-apenella-go-ansible

[Nilesh Patra]

On Sun, Dec 24, 2023 at 01:41:39PM +0530, Ananthu C V wrote:
> It looks that this has been a clear oversight from my side. *I do find this a 
> very useful library*
> but as you mentioned, since go team convention does not include packaging 
> libaries that are not
> needed by any binaries, there is probably no real value in getting this in.

It is not a go-team convention as such. In principle library packages can be 
packaged as well. However
there is no utility in doing so. At the end of the day, a user only wants the 
necessary tools.

The situation is quite different from python or javascript (where you work). In 
those teams, once you
install python lib or a js lib, you can use it for your development w/o any 
extra hurdles. All imports/functionalities
would work just fine. However, in go packages, you need to change the 
GOPATH/GOROOT to actually import and
use those packages. This makes close to no sense for anyone to do, and simply 
using a go get is the most simple way.

Adding in lib packages that effectively won't be used also calls for extra 
maintenance burden on the team so
at least I find it sensible to add lib packages only when there's a use for 
them.

> As such, please prune the corresponding repositories for the following:
> - golang-github-apenella-go-ansible
> - golang-github-apenella-go-common-utils
> - golang-github-sosedoff-ansible-vault-go

Pruned!

> I feel sincerely sorry that an oversight from my side has ended up taking 
> some of your busy schedule
> and I apologize for making you spend your time needlessly. I'll try my best 
> to make sure such mishapas
> does not occur in the future, since it is not beneficial to anyone. And 
> regardless of the outcome of
> this, thanks a lot for taking a look at the RFS.

Don't worry about it, thanks for working on these regardless!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055192: RFS: golang-github-apenella-go-ansible

[Nilesh Patra]

I finally got some time to look at this. From what I see, this is just a library
package (and no binary) and this seems to be the final package you want to get 
uploaded.

Generally, all go library packages 'are'/'should be' present in Debian because 
they are needed
for a target (binary) package which a user is interested in using. No-one would 
be keen
on apt installing golang libraries and fiddling with GOPATH/GOROOT
rather than a simpler `go get -u` if they want to use them to write code.

Hence, unless you have any target packages for which these libs are needed, I 
do not see
a lot of use of getting this in. Let me know what you'd think. I *do* expect 
your reponse on this.

Thanks!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1053000: RFS: golang-github-google-gnostic-models/0.6.8-1 [ITP] -- Protocol buffer models for gnostic

[Nilesh Patra]

On Fri, Dec 22, 2023 at 12:49:34PM +0100, Nicolas Schier wrote:
> thanks a lot for your review!  I fixed all four points (and updated the
> debian/watch version) so lintian is now completely satisfied.
> 
> The corresponding fixup commit is pushed to
> 
>   
> https://salsa.debian.org/go-team/packages/golang-github-google-gnostic-models.git

Uploaded to NEW. Thanks for contributing!

> (TIL: I should always push 'UNRELEASED' to the git repos as long as the
> package is not completely reviewed and accepted.)

Yep!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo

[Nilesh Patra]

On Fri, Dec 22, 2023 at 06:03:11AM +0100, Nicolas Schier wrote:
> On Thu, Dec 21, 2023 at 11:01:23PM +0530 Nilesh Patra wrote:
> > On Wed, Dec 20, 2023 at 09:49:48AM +0100, Nicolas Schier wrote:
> > > On Wed, Dec 20, 2023 at 09:44:31AM +0100 Nicolas Schier wrote:
> > > ah, I forgot to mention that 'uscan' does choose the "correct" upstream 
> > > version
> > > tag automatically:
> > > [...]
> > > > Can someone please remove the protected branch 'upstream' as well as the
> > > > upstream tag 'upstream/1.25.0_alpha0'?
> > > > 
> > > > (Or remove the whole repo to allow re-creating it?)
> > 
> > Do you still want the repo to be pruned or remove the upstream branch?
> 
> yes, please.

Pruned the repo. HTH

> > > > [1]: 
> > > > https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1012720: RFS: golang-github-google-gnostic-models/0.6.8-1 [ITP] -- Protocol buffer models for gnostic

[Nilesh Patra]

On Wed, Dec 20, 2023 at 08:35:38AM +0100, Nicolas Schier wrote:
> Hi,
> 
> I've packaged golang-github-google-gnostic-models, and I need a sponsor
> to get it uploaded.  The package is a requirement for golang-k8s-apimachinery
> (cp. #1012720).

Few comments:

* You do not need a separate hand-crafted .install files to install extra 
things you need.
  Please use DH_GOLANG_INSTALL_EXTRA in d/rules for that.
* The d/copyright should probably mention "Google LLC" instead of "Google Inc." 
since that's
  what is mentioned in all the source code files.
* Standards version can be updated to 4.6.2
* README.md as docs can be dropped. In principle no-one would install a lib 
package and read the
  README. The lib packages in golang are mainly needed for target consumable 
binary packages.

LMK once you address them!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo

[Nilesh Patra]

On Wed, Dec 20, 2023 at 09:49:48AM +0100, Nicolas Schier wrote:
> On Wed, Dec 20, 2023 at 09:44:31AM +0100 Nicolas Schier wrote:
> ah, I forgot to mention that 'uscan' does choose the "correct" upstream 
> version
> tag automatically:
> [...]
> > Can someone please remove the protected branch 'upstream' as well as the
> > upstream tag 'upstream/1.25.0_alpha0'?
> > 
> > (Or remove the whole repo to allow re-creating it?)

Do you still want the repo to be pruned or remove the upstream branch?

> > [1]: https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git 

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055192: RFS: golang-github-apenella-go-ansible

[Nilesh Patra]

On Sat, Dec 16, 2023 at 01:49:18PM +0530, weepingclown wrote:
> Thanks a lot for this and I really appreciate it, especially considering it 
> has been a while (~6weeks) since I've sent this RFS.
> [...]
> Now, I'd appreciate if there is someone who could sponsor this in the go 
> team. That includes uploading the two dependencies of this; 
> apenella-go-common-utils and sossedoff-vault-go.
> Hoping to find a sponsor this time.

@weepingclown: Maybe I am the one to blame here, sorry about this.
Your mails did not hit my mailbox for whatever reason and I've been too
occupied with RL to have taken a look anytime soon.

I'll upload these when I get some breathing space. Feel free to ping me in 
about 2
weeks if you see no activity on this.

@Maytham: If I happened to miss commenting on any of your RFS request that's 
already
sponsored, let me know.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1057970: RFS: protoc-gen-validate

[Nilesh Patra]

On Sun, Dec 17, 2023 at 03:05:39PM +0800, Maytham Alsudany wrote:
> Hi Go team,
> 
> I'm looking for a sponsor to upload protoc-gen-validate.
> 
> Adding to the protoc-gen-star thread since these packages are related.
> 
> Salsa: https://salsa.debian.org/go-team/packages/protoc-gen-validate
> 
> Dependency tree:
> golang-github-envoyproxy-protoc-gen-validate
> └── golang-github-lyft-protoc-gen-star

I vaguely remember you/someone else mentioning on IRC that this is not needed.
Am I mistaken? LMK if so an I'll upload.

Also, are these needed for a target package?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1057890: RFS: golang-github-abadojack-whatlanggo

[Nilesh Patra]

On 10 December 2023 3:58:18 pm IST, Maytham Alsudany  
wrote:
>Hi Go team,
>
>I've packaged golang-github-abadojack-whatlanggo, and I need a sponsor to get 
>it
>uploaded.
>
>Salsa:
>https://salsa.debian.org/go-team/packages/golang-github-abadojack-whatlanggo
>
>Changelog:
>
>golang-github-abadojack-whatlanggo (1.0.1-1) UNRELEASED; urgency=medium
>
>  * Initial release (Closes: #1057890)
>
> -- Maytham Alsudany   Thu, 07 Dec 2023 18:46:25 
> +0800\

Uploaded.

>The package builds with sbuild successfully, and passes autopkgtest, lintian,
>and piuparts.

Thanks
Nilesh

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Sat, Nov 11, 2023 at 12:57:38PM +0800, Maytham Alsudany wrote:
> Upstream uses sphinx to generate both the HTML docs and the manpages,
> so perhaps we should update sphinx's man_pages[4] option in
> docs/conf.py[5] in a PR and/or patch, adding a kitten manpage that
> points to an existing/new RST file.

Ah, right!

> > > Regarding the inconsistent shebangs in the Python files, I've opened an
> > > issue upstream regarding that[3].
> > 
> > Yep, and it seems to have been changed to "usr/bin/env python" instead in 
> > the fixing commit :-/
> > 
> > Seems like we will have to keep the `sed` call for a while.
> 
> With the experience you have packaging software written in Python, is
> it standard to use "python" or "python3" in shebangs? The fixing commit
> references PEP 394[6], which allows either shebang.

I have seen python as being more common. Possibly because people use
venv for python stuff and that always has a bin/python executable.

> > > Regarding splitting up the kitty and kitten components, I've opened an
> > > issue upstream[2], but the upstream author promptly closed it, stating
> > 
> > Something similar happened with me when I forwarded
> > 
> > 
> > 
> > Upstream which I can reproduce and it was closed very quickly.
> > 
> > My impression is that the upstream is somewhat tricky to deal with - but I 
> > guess with time, we will manage somehow.
> 
> I guess we'll have to stick to patching bugs ourselves.

For now, I suppose that'd be the case.

> > > that "the Go code depends on the rest of the code so splitting it is
> > > not going to happen."
> > 
> > I've added a comment there. Let's see if they consider to do something 
> > about it.
> 
> I'm assuming you've seen upstream's reply.

I did. Maybe we will switch to a non-dhgolang layout if this continues
to be an issue. I used this because it avoid symlinking everything
that'd there in usr/share/gocode and automates the built-using field
thingy etc.
We will re-evaluate this at a later point.

> Hopefully we can get kitty to be stable enough to move into unstable,
> I'm excited to see it propagate into testing!

I will meanwhile ask a couple of people to test out the new kitty
package.

BTW, oddly enough kitty is failing its build on ppc64el[7] which will
block migration. The tests failing in the question are trying to open a
PTY, which I suppose ppc64 does not like. I am in favor of skipping
these on that architecture, if you're fine with that.

> Regarding lintian's errors, would you like me to add descriptions to
> your patches (by that, I mean copy-paste your commit messages)?

Ah, sure. I had been lazy to not do that.

> Additionally, I keep forgetting to mention that lintian.debian.org
> seems to not work,

I am also involved with lintian maintenance in "some" capacity and
while getting lintian.d.o is in TODO, no-one realistically has the time
for that.

Lintian.d.o has been effectively replaced with its UDD counterpart[7]

> so I've had to resort to `lintian-explain-tags`. I
> don't think it's supposed to be that way.

Agreed. There's a plan to implement tag explanations within UDD at some
point as has been pointed out in this thread[8].

> > > [1]: https://github.com/kovidgoyal/kitty/issues/6808
> > > [2]: https://github.com/kovidgoyal/kitty/issues/6809
> > > [3]: https://github.com/kovidgoyal/kitty/issues/6810
> [4]:
> https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-man_pages
> [5]: https://github.com/kovidgoyal/kitty/blob/master/docs/conf.py#L178
> [6]: https://peps.python.org/pep-0394/
[7]: https://wiki.debian.org/UltimateDebianDatabase/ReplacingLintianDebianOrg
[8]: https://lists.debian.org/debian-devel/2023/09/msg00394.html

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On 11 November 2023 8:31:25 am IST, Maytham Alsudany  
wrote:
>On Sat, 2023-11-11 at 02:31 +0530, Nilesh Patra wrote:
>> My personal experience is that maintainer maintained manpages are
>> seldom well-maintained and tend to get outdated with new versions
>> if the maintainer forgets to update these regularly.
>> Also, that manpages keep introducing new lintian warnings with new
>> version of troff/groff.
>> 
>> Since this package already requires some maintenance, I feel it would be
>> an additional burden on me and you. It is IMHO the best case scenario if
>> the upstream maintains a manpage themselves.
>
>Opened an issue upstream[1].

Since they said PRs are welcome, maybe we could send them a manpage and a 
script to recreate it everytime.
I think createmanpages script could be handy

<https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages>

>Regarding the inconsistent shebangs in the Python files, I've opened an
>issue upstream regarding that[3].

Yep, and it seems to have been changed to "usr/bin/env python" instead in the 
fixing commit :-/

Seems like we will have to keep the `sed` call for a while.

>Regarding splitting up the kitty and kitten components, I've opened an
>issue upstream[2], but the upstream author promptly closed it, stating

Something similar happened with me when I forwarded

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054633>

Upstream which I can reproduce and it was closed very quickly.

My impression is that the upstream is somewhat tricky to deal with - but I 
guess with time, we will manage somehow.

>that "the Go code depends on the rest of the code so splitting it is
>not going to happen."

I've added a comment there. Let's see if they consider to do something about it.

>I may open PRs for [1] and [3] to ensure they're fixed quickly.
>
>Would you like me to bump the version of the package to 0.31.0 now that
>0.30.1 has been uploaded to experimental?

Sure, if you have the time! :)

>[1]: https://github.com/kovidgoyal/kitty/issues/6808
>[2]: https://github.com/kovidgoyal/kitty/issues/6809
>[3]: https://github.com/kovidgoyal/kitty/issues/6810

Best,
Nilesh

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

Hi Maytham,

On Fri, Nov 10, 2023 at 05:15:22PM +0800, Maytham Alsudany wrote:
> On Thu, 2023-11-09 at 00:32 +0530, Nilesh Patra wrote:
> > * Can you please clean up some of the lintian stuff? And then we could
> >   upload the new release.
> 
> Letting you know that I've fixed the majority of lintian's errors/warnings, 
> and
> the latest report now looks like this[1].

Awesome, thank you!

> If would be good to get a second pair of eyes on my commits, since I've made
> some decisive patches.

I have removed all commits adding manpage. Furthermore you added a
compress command to dh_auto_test this would lead to installing different
manpage based on whether or not tests are run (for instance skipped via
nocheck). This is a bug, IMHO.

My personal experience is that maintainer maintained manpages are
seldom well-maintained and tend to get outdated with new versions
if the maintainer forgets to update these regularly.
Also, that manpages keep introducing new lintian warnings with new
version of troff/groff.

Since this package already requires some maintenance, I feel it would be
an additional burden on me and you. It is IMHO the best case scenario if
the upstream maintains a manpage themselves.

You may wonder that it might be possible to add a help2man directive in
d/rules to fix this problem, but then this gets the package to not be
able to cross-build and the problem with troff still remains. Go
binaries do not natively cross-build via debian way of cross-compilation
via hostarch yet but I suppose it would one day.

> If all's good, then I reckon that the new release is ready to be uploaded.

Pushed to experimental; thank you for your work! \o/

> You probably already know, but upstream released version 0.31.0 a few days 
> ago,
> which makes the version we're working on (0.30.1) outdated. I think we should 
> do
> a version bump after we upload 0.30.1 so we have a working package uploaded,
> even if it's one version old. The version bump can also act as a stability
> check, to see if the package still builds successfully when the version gets
> bumped.

Agreed, and thanks again! :D

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

Hi Maytham,

On Fri, Nov 10, 2023 at 01:38:05PM +0800, Maytham Alsudany wrote:
> On Thu, 2023-11-09 at 22:53 +0530, Nilesh Patra wrote:
> > > Regarding commit 7020dd5d:
> > > Are the ldflags necessary, since the binary builds fine without them set?
> > > Especially the kitty.VCSRevision option, which is only really used in 
> > > --version,
> > > as shown in this upstream commit[9].
> > 
> > I do not find any commit at [9] but rather the lintian output. I simply
> > decided to emulate the way in which upstream buildsystem would behave to
> > avoid surprises so I'd be OK with keeping it that way. LMK if you
> > disagree.
> 
> Sorry, wrong link. I meant [10]. But I don't think this applies anymore, as 
> the
> tools/cli/infrastructure.go file has been removed.
> 
> I cloned the upstream repo, built it using setup.py, and passed the build 
> option
> `--vcs-rev=VCS_REV_GOES_HERE`. After running `strings ./kitty/launchers/kitty 
> |
> grep -i VCS_REV_GOES_HERE`, and the same with the kitten binary, no mention of
> the VCS revision was found, except for the following in "kitten":
> 
> build   -ldflags="-X kitty.VCSRevision=VCS_REV_GOES_HERE"
> build   -ldflags="-X kitty.VCSRevision=VCS_REV_GOES_HERE"
> 
> So I don't think it matters whether we pass the VCSRevision in ldlags or not,
> nor what value we pass, since it's not being used.
> 
> I agree with passing the other ldflags though, in order to emulate setup.py 
> and
> the upstream buildsystem.
> 
> Forgive me for overemphasizing this, but I wanted to get to the bottom of 
> this.

No worries, thank you for pushing this. I am convinced that this serves
no real purpose so I removed in from d/rules.

> > That said I do see a directive to "/usr/bin/env python3" in specific
> > files for instance in "kittens/tui/handler.py" "kitty/fonts/render.py"
> > but not in others. IMHO we should ask upstream to maintain uniformity by
> > fixing this.
> 
> I agree. Should we open an issue and/or PR upstream?

Yes, if you could open an issue, it'd be nice!

> I'm fine with that. You've got more experience, whereas this is my first time
> contributing to a Debian package, so I reckon you should be the "Maintainer" 
> of
> the package, if you're fine with it.

It is hard for me to believe that you are contributing to debian package
for the first time, as all your contributions seem to be of high quality
which is not something I see in newcomers, so kudos for that!

> Just a thought: should we get the Python and Golang teams involved, since both
> programming langs are being used and both dh buildsystems are being used?

As such no, all packages in the debian/ namespace as such belong to a
particular language and we will keep involving maintainer teams for all
such packages.
IMHO there's nothing these two teams would do
together for such a package, and I'm (very) active in both the teams
so I say this with some confidence :)

> > > Perhaps splitting up the kitty and kittens components into separate
> > > folders/repos? Or make it so that these components can build 
> > > independently of
> > > each other (setup.py builds kitty only, `go build` builds kittens only)?
> > 
> > Yes, I agree. While I was doing the work of making the go part work, I
> > felt that it'd indeed be more sensible if "kitten" was a separate repo
> > altogether.
> 
> Should we bring this up on upstream's issue tracker?

Absolutely!

> Another option would be to split the repos ourselves on GitHub (under the 
> Debian
> org), which requires more work on our part but is more likely to get the
> upstream author to accept our proposal:
>  1. Fork github.com/kovidgoyal/kitty to github.com/debian/kitty

As such I don't think the debian namespace has got anything to do with
this. You could just fork it to your own :)

>  2. Remove all "kitten" components from the fork
>  3. Create github.com/debian/kitten and move all the Golang "kitten" 
> components
> to it
>  4. Open a PR to merge debian/kitty to kovidgoyal/kitty
>  5. In the PR, offer to transfer ownership of debian/kitten (or let the 
> upstream
> author just copy/fork it themselves)

I think this is a little hurried and upstream may not even want
something like that. I suppose it'd be more sensible to first *ask* the
upstream as to what they think about the concerns and we can go about
sending patches once we reach some concensus.

> > > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037440#37
> > > > > [2]: https://salsa.debian.org/Maytha8/kitty-

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Fri, Nov 10, 2023 at 12:05:20AM +0800, Maytham Alsudany wrote:
> On Thu, 2023-11-09 at 00:32 +0530, Nilesh Patra wrote:
> > > On the contrary, avoiding the use of dh-golang as done in this repo[3] 
> > > causes
> > > all the tests to pass without problem, and I'm unsure to why that is.
> > 
> > This was due to some caveats with the build system and also how
> > dh_golang works. We added in a patch that'd skip running gen-go-code.py
> > and this was being used at more than one place.
> 
> Doesn't the update_go_generated_files function in setup.py[6] run gen-go-
> code.py, specifically `kitty +launch gen-go-code.py`? Patch#0003[7] adds the
> `return` statement right afterwards.

Yeah, that was a mis-type from my end. I meant to say
"build_static_kittens" function instead from where we are returning and
building the kitten binary on our own.

The line:
`"HOME="$(HOME)" KITTY_RUNTIME_DIRECTORY="$(KITTY_RUNTIME_DIRECTORY)" 
python3 setup.py $(V) build-launcheri` 

in the tests in d/rules calls "build_static_kittens(args, 
launcher_dir=launcher_dir)" and this seems to build
the kittens binary 'again' in kitty/launcher which did not work for us
because we patched out the function altogether.

What I did to get around this is to simply symlink the already created
kittens binary - that got the python tests passing. Let me know if this
is still unclear.

> > > We may have to take the approach Fedora has taken, where they've skipped 
> > > any
> > > continuously failing tests[4].
> > 
> > For now I disabled two tests in the go code that tries to fiddle with
> > proc/devfs and can potentially fail in a chroot. Python tests probably
> > also try to do some non-standard stuff and we could disable it later if
> > it goes flaky on the buildd machines.
> 
> If we have time, it's probably good to get to the bottom of these flaky tests
> and patch them instead of skipping them outright.

I did not dig very deep but I have some pointers.

The two go tests skipped are:
* TestCreateAnonymousTempfile - my *hunch* this very likely fails due to it 
trying
  to do $things with procfs. This test does not fail for me in my base
  system but rather in a chroot.
* TestHintMarking - I am not sure why this fails but I observed the
  failure even when I tried in the upstream repo. Not 100% sure if I ran it
  the right way but since it failed anyway, I considered skipping it.

I hope that provides some justification.

> This may involve filing bug reports upstream, and
> creating PRs when necessary upstream in order to improve
> their test suites for both Python and Golang.

Agreed, and I would love some coordination/help with this bit.

> > That said, I want to discuss/ask a few things:
> > * Can you take a look at my commits and let me know if you have any
> >   comments?
> 
> Regarding commit 38ea7407:
> This is a nitpick (and I think this is a mistake): should the patch file end
> with .patch instead of .py? 

This was an oversight at my end - fixed - Thanks.

> It would probably be beneficial if we could setup the gbp workflow by hand,
> ensuring the upstream branch is up to date

Not sure what you mean here. `gbp import-orig` takes care of it.

> and setting up a patch-queue/debian/(unstable|experimental) branch.

No, please. These are never really meant to be pushed. Besides people use 
different
way to apply patches - I use quilt and not `gbp pq`.

> Regarding commit d847dbfe:
> The d/ch entry needs some cleaning up, with the merging and removal of some
> points. (I'm assuming you used `gbp dch`.)
> 
> For example,
> >   * patch: make setup.py compatible with GOPATH mode
> is probably not something the end user needs to know about.

But we (as maintainers) do. I also find changelog a sensible way to keep track 
of our
changes and I find it helpful to go back in time to see when a certain
change was done and what was the state of the repository then to compare
with the current version so as to re-assess whether the change done back
then makes sense now.

> Let me know if I should leave it or clean it up.

I prefer that you leave it.

> Regarding commit 7020dd5d:
> Are the ldflags necessary, since the binary builds fine without them set?
> Especially the kitty.VCSRevision option, which is only really used in 
> --version,
> as shown in this upstream commit[9].

I do not find any commit at [9] but rather the lintian output. I simply
decided to emulate the way in which upstream buildsystem would behave to
avoid surprises so I'd be OK with keeping it that way. LMK if you
disagree.

> > * Can you please clean up some of the lintian stuff? And then we could
> >   upload the new release.
> 
> The lates

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Wed, Nov 08, 2023 at 05:52:05PM +0800, Maytham Alsudany wrote:
> On the contrary, avoiding the use of dh-golang as done in this repo[3] causes
> all the tests to pass without problem, and I'm unsure to why that is.

This was due to some caveats with the build system and also how
dh_golang works. We added in a patch that'd skip running gen-go-code.py
and this was being used at more than one place.

I've fixed up the build and the tests and the package seems to
build/work. I suppose we should be pushing it to debian experimental for
now since this introduces some completely new things. Let me know if you
disagree.

I've pushed all my changes to the debian/experimental branch on the
existing salsa repo[5] and also added your access to it so you could
push directly.

> We may have to take the approach Fedora has taken, where they've skipped any
> continuously failing tests[4].

For now I disabled two tests in the go code that tries to fiddle with
proc/devfs and can potentially fail in a chroot. Python tests probably
also try to do some non-standard stuff and we could disable it later if
it goes flaky on the buildd machines.

That said, I want to discuss/ask a few things:
* Can you take a look at my commits and let me know if you have any
  comments?
* Can you please clean up some of the lintian stuff? And then we could
  upload the new release.
* Since we both are interested in kitty's packaging, I think we have two
  options:
  - Either you or me would be in the "Maintainer" field and the other one would
be in "Uploader" field.
  - Add ki...@packages.debian.org as the maintainer and add both of us
as uploaders (that means we subscribe to the package email
ofcourse).
  Which one do you think we should do?
* I suppose the maintenance of this package will keep getting messy due
  to upstream mixing up two language build systems in a fairly non-standard way.
  I suppose it makes sense to ask upstream if they'd consider to switch
  to something that eases maintenance burden on us (Debian). WDYT?

> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037440#37
> [2]: https://salsa.debian.org/Maytha8/kitty-dh-golang
> [3]: https://salsa.debian.org/Maytha8/kitty
> [4]: https://src.fedoraproject.org/rpms/kitty/blob/rawhide/f/kitty.spec#_268
[5]: 
https://salsa.debian.org/debian/kitty/-/tree/debian/experimental?ref_type=heads

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Tue, 07 Nov 2023 16:33:42 +0800 Maytham Alsudany  
wrote:
> I'd like to adopt the kitty package if that's ok.
> 
> I've been able to upgrade the package to the latest version and get the
> Go part of the package to build successfully (the new 'kittens'
> feature). My efforts can be found at
> https://salsa.debian.org/Maytha8/kitty

Looks like we ended up with some duplicate effort here.

I tried avoiding:

| mkdir -p $(BUILDDIR)/src
| ln -s /usr/share/gocode/src/* $(BUILDDIR)/src
| ln -s $(CURDIR) $(BUILDDIR)/src/kitty

With the call to go-specific dh_auto_configure. I did some other changes of
similar sort on the lines of dh-golang toolchain as well.

However your changes to setup.py are probably more sensible than mine :)

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Tue, 07 Nov 2023 16:45:18 +0800 Maytham Alsudany  
wrote:
> Hi,
> 
> Firstly, I'd like to apologise for the duplicate mail, which was an
> accident on my part.
> 
>OTOH, I did take a look at the errors and I see two ways. Either >
>patch out all the go build related code and use debian's go build
>toolchain (which takes care of a bunch of things) or hack around the
>way upstream builds to somehow fit out usecase (this is consuming
>quite some cycles).
> 
> I'll outline what method I've used:
> 
> What I've done is setup all the correct environment variables for the
> Go compiler, as well as patch the setup.py file to work with
> GO111MODULE=off. (I did this by looking at the dh-golang source code
> and copying what it does.)
> 
> I'm worried about using dh-golang directly, since passing --
> buildsystem=golang may break the other parts of the build.

There's a patch in[1] that gets things moving.

@James: Since you agreed to maintain this package as I offer my help for
the go stuff, do you think it makes sense to convert this into an RFH
instead of RFA/ITA?

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037440#37
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055347#19

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: RFA: kitty -- fast, featureful, GPU based terminal emulator

[Nilesh Patra]

On Sat, Nov 04, 2023 at 02:25:47PM -0400, James McCoy wrote:
> We can try that for the now, but it would probably be good for someone
> else to eventually take over primary maintenance of the package.
> 
> https://salsa.debian.org/debian/kitty/-/merge_requests/3 is what I have
> so far for the new upstream version.  Feel free to hack around with
> that.

Cool. I have one question though: how do you sync the repo to new
upstream? It does not seem to use gbp layout so wanted to know how
exactly you're tracking/pulling the commits?

OTOH, I did take a look at the errors and I see two ways. Either patch
out all the go build related code and use debian's go build toolchain
(which takes care of a bunch of things) or hack around the way upstream
builds to somehow fit out usecase (this is consuming quite some cycles).
Definitely complicated since a bunch of different functionalities have
been mixed with different languages.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: RFA: kitty -- fast, featureful, GPU based terminal emulator

[Nilesh Patra]

Hi,

On Sat, Nov 04, 2023 at 12:23:34PM -0400, James McCoy wrote:
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: ki...@packages.debian.org, debian-de...@lists.debian.org
> Control: affects -1 + src:kitty
> 
> I request an adopter for the kitty package.  I no longer use the package
> and don't have time to figure out how to deal with the new golang parts
> of the package.

If you could commit to maintaining the overall package as such, I am offer
my help with the golang parts.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1037446: RFP: golang-github-seancfoley-ipaddress-go -- Go library for handling IP addresses and subnets, both IPv4 and IPv6

[Nilesh Patra]

Control: retitle -1 ITP: golang-github-seancfoley-ipaddress-go -- Go library 
for handling IP addresses and subnets, both IPv4 and IPv6
Control: owner -1 mirth.hickf...@gmail.com

>   IP address and network manipulation, CIDR, operations, iterations,
>   containment checks, longest prefix match, subnetting, and data
>   structures, with polymorphic code
> 
> This needed to package new upstream version of kitty.

You need to convert RFP into ITP whenever you want to package something
that is an RFP. Please keep that in mind for future.


signature.asc
Description: PGP signature

Bug#1054565: RFP: golang-github-zeebo-xxh3 -- XXH3 algorithm in Go

[Nilesh Patra]

Control: retitle -1 ITP: golang-github-zeebo-xxh3 -- XXH3 algorithm in Go
Control: owner -1 rica...@marliere.net

On Mon, 30 Oct 2023 18:28:54 -0300 "Ricardo B. Marliere"  
wrote:
> On 23/10/25 09:19PM, James McCoy wrote:
> > Package: wnpp
> > Severity: wishlist
> > Control: block 1037440 by -1
> > 
> > * Package name: golang-github-zeebo-xxh3
> >   Version : 1.0.2-1
> >   Upstream Author : Jeff Wendling
> > * URL : https://github.com/zeebo/xxh3
> > * License : BSD-2-clause
> >   Programming Lang: Go
> >   Description : XXH3 algorithm in Go
> > 
> >  XXH3
> >  .
> >  GoDoc (https://godoc.org/github.com/zeebo/xxh3) Sourcegraph
> >  (https://sourcegraph.com/github.com/zeebo/xxh3?badge) Go Report Card
> >  (https://goreportcard.com/report/github.com/zeebo/xxh3)
> >  .
> >  This package is a port of the xxh3 (https://github.com/Cyan4973/xxHash)
> >  library to Go.
> >  .
> >  Upstream has fixed the output as of v0.8.0, and this package matches
> >  that.
> > 
> > This is needed to package a new upstream version of kitty.
> > 
> > Cheers,
> > -- 
> > James
> > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
> > 
> 
> Hello James,
> 
> please consider reviewing for uploading the following:
> 
> https://salsa.debian.org/go-team/packages/golang-github-zeebo-assert
> https://salsa.debian.org/go-team/packages/golang-github-zeebo-xxh3

You need to convert RFP into ITP whenever you want to package something
that is an RFP. Please keep that in mind for future.


signature.asc
Description: PGP signature

Bug#1051983: RFS: golang-github-katalix-go-l2tp

[Nilesh Patra]

On Tue, Oct 17, 2023 at 09:27:38PM +0100, Tom Parkin wrote:
> On  Wed, Oct 18, 2023 at 01:38:58 +0530, Nilesh Patra wrote:
> > I've uploaded your package to NEW. However, please look at my commits.
> 
> Thank you very much :-)
> 
> I've just had a look at your changes on the debian/0.1.6-1 tag.  Thank
> you for catching the copyright for l2tp.h!
> 
> Should I merge these changes on debian/sid?

I think they are already in the same branch, no?


https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp/-/commits/debian/sid

We tag debian releases with debian/ tag for easy tracking. LMK if I
misunderstood something.

> > I also have a quick question -- is the interface of the library somehow
> > architecture dependent? if so the "M-A: foreign" field should be
> > dropped.
> 
> No, it shouldn't be.

Cool, thanks for the prompt reply!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1052019: RFS: golang-github-gookit-color/1.5.4-1

[Nilesh Patra]

On Wed, Oct 04, 2023 at 02:20:38PM +0530, Afeedh Shaji wrote:
> I am looking for a sponsor for the package "golang-github-gookit-color".
> This package is a prerequisite for upcoming package "lazygit" (#908894).
> 
> I pushed to our team's Salsa:
> 
>   https://salsa.debian.org/go-team/packages/golang-github-gookit-color
> 
> Could you please reviewing/sponsoring this?
> Any kind of reviews and suggestions are appreciated.

Uploaded. However please look at my commits.

Thanks for your contribution!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1053520: RFS: golang-github-ozeidan-fuzzy-patricia/3.0.0-1

[Nilesh Patra]

On Sun, Oct 08, 2023 at 11:31:14AM +0530, Ananthu C V wrote:
> I am looking for a sponsor for the package 
> "golang-github-ozeidan-fuzzy-patricia".
> This package is a prerequisite for upcoming package "lazygit" (#908894).
> 
> I pushed to our team's Salsa:
> 
>   
> https://salsa.debian.org/go-team/packages/golang-github-ozeidan-fuzzy-patricia
> 
> Could you please review/sponsor this?
> Any kind of reviews and suggestions are appreciated

Please fix the description in d/control. Also IMHO the copyright holder
should be as per what's mentioned in the license and authors file, not
as per repository owner -- update that too.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1051983: RFS: golang-github-katalix-go-l2tp

[Nilesh Patra]

I've uploaded your package to NEW. However, please look at my commits.

I also have a quick question -- is the interface of the library somehow
architecture dependent? if so the "M-A: foreign" field should be
dropped.

Thanks for your contribution!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1053520: ITP: golang-github-ozeidan-fuzzy-patricia -- A generic patricia trie (also called radix tree) implemented in Go (Golang).

[Nilesh Patra]

Control: forcemerge -1 1053518

I'm merging the bugs since both are ITPs with the same description.

On Thu, Oct 05, 2023 at 08:01:21PM +0530, Ananthu C V wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ananthu C V 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
> 
> * Package name: golang-github-ozeidan-fuzzy-patricia
>   Version : 3.0.0
>   Upstream Author : Omar Zeidan
> * URL : https://github.com/ozeidan/fuzzy-patricia.git
> * License : Expat 
>   Programming Lang: Go
>   Description : A generic patricia trie (also called radix tree) 
> implemented in Go (Golang).
> 
> A generic patricia trie (also called radix tree) implemented in Go (Golang).
> 
> The patricia trie as implemented in this library enables fast visiting of 
> items in some particular ways:
> 
> visit all items saved in the tree,
> visit all items matching particular prefix (visit subtree), or
> given a string, visit all items matching some prefix of that string.
> 
> []byte type is used for keys, interface{} for values.
> 
> Trie is not thread safe. Synchronize the access yourself.
> 
> This package is in the dependency tree of Lazygit (#908894)
> 


signature.asc
Description: PGP signature

Bug#1053518: ITP: golang-github-ozeidan-fuzzy-patricia -- A generic patricia trie (also called radix tree) implemented in Go (Golang).

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-ozeidan-fuzzy-patricia
  Version : 3.0.0
  Upstream Author : Omar Zeidan
* URL : https://github.com/ozeidan/fuzzy-patricia.git
* License : Expat 
  Programming Lang: Go
  Description : A generic patricia trie (also called radix tree) 
implemented in Go (Golang).

A generic patricia trie (also called radix tree) implemented in Go (Golang).

The patricia trie as implemented in this library enables fast visiting of items 
in some particular ways:

visit all items saved in the tree,
visit all items matching particular prefix (visit subtree), or
given a string, visit all items matching some prefix of that string.

[]byte type is used for keys, interface{} for values.

Trie is not thread safe. Synchronize the access yourself.

This package is in the dependency tree of Lazygit (#908894)

Bug#1052175: ITP: golang-github-yuin-goldmark-highlighting-v2 -- A Syntax highlighting extension for the goldmark markdown parser (v2)

[Nilesh Patra]

On Mon, Sep 18, 2023 at 06:03:12PM +, Peymaneh wrote:
> * Package name: golang-github-yuin-goldmark-highlighting-v2
>   Version : 0.0~git20230729.37449ab-1
>   Upstream Author : Yusuke Inuzuka
> * URL : https://github.com/yuin/goldmark-highlighting
> * License : Expat
>   Programming Lang: Go
>   Description : A Syntax highlighting extension for the goldmark markdown 
> parser.
> 
> This package provides github.com/yuin/goldmark-highlighting/v2
> 
> Version 1 is packaged in Debian as golang-github-yuin-goldmark-highlighting
> 
> Version 2 is needed for updating Caddy.

Looking at the commits, between the latest commit (37449ab) and the one
in debian (594be19) is close to negligible.

The version of alecthomas/chroma is bumped to v2 and there are some
modifications made in the testing code (highlighting_test.go), that's all.
I'm confused as to why upstream decided to bump * their own version * as well.

Do you think it makes sense to clarify with them on this part?

Also, time being, if you just try to also add another (v2) import path
to yuin-goldmark-highlighting and try to build caddy, does it work? (I'm
guessing it ideally should since there's no change).

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1043408: ITP: golang-github-dsnet-compress -- Collection of compression related Go packages.

[Nilesh Patra]

On Thu, 10 Aug 2023 19:16:55 +0545 Nisha Pariyar  
wrote:
> * Package name: golang-github-dsnet-compress
>Version : 0.0.1-1
>Upstream Author : Joe Tsai
> * URL : https://github.com/dsnet/compress
> * License : BSD-3-clause
>Programming Lang: Go
>Description : Collection of compression related Go packages.
> 
>   Collection of compression libraries for Go
>   .
>   A collection of pure Go libraries for popular compression algorithms,
>   designed to extend the Go standard library capabilities. Includes
>   implementations of Brotli (RFC 7932), BZip2, DEFLATE (RFC 1951), and
>   XFLATE formats. Offers a balance between maintainable code,
>   performance, and flexibility. Active development; API stability not
>   guaranteed. Requires Go 1.9+.

I wanted to ask a couple of questions before I start with a review:

* Is there a package that needs dsnet/compress? If so, which one - and
  is it a crucial dependency?
* The README says that:
NOTE: This library is in active development. As such, there are no 
guarantees about the stability of the API.
The author reserves the right to arbitrarily break the API for any 
reason.

This does not sound very good in debian's context. Breaking APIs in
major releases are still OK, but I'm a little concerned about this in
for instance patch/minor releases.

* There's a compression library https://github.com/klauspost/compress
  which is already in debian (golang-github-klauspost-compress). The
  additional functionality that dsnet/compress seems to provide is
  brotli compression/decompression. If this is not used eventually
  (assuming this package is dep of another package that you're trying to get in)
  do you think it'd be possible to patch the code and convince upstream?

In principle I'd have just started with a review and uploaded eventually
but the API problem made me re-think.

Let me know.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1051940: RFS: golang-github-stefanhaller-tcell/0.0~git20230806.2dfa11e-1 [ITP]

[Nilesh Patra]

On Thu, Sep 14, 2023 at 08:46:07PM +0530, Jongmin Kim wrote:
> I am looking for a sponsor for the package "golang-github-stefanhaller-tcell".
> This package is a prerequisite for the package "lazygit" (#908894)[1,2].
> 
>   [1] https://bugs.debian.org/908894
>   [2] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph
> 
> The package upstream[3] is a forked version of tcell[4] which is already
> packaged in Debian archive[5]. However, the package is needed due to
> forked upstream modified some functions[6] for lazygit, which have
> discrepency from the original.

I think this is not needed at all. The only delta it has with gdamore/tcell is 
this
commit[7] which has been merged into upstream (gdamore/tcell) now, see[8].

And digging into lazygit's commits, you'd see that the change of fork in 
go.mod[9] has the
commit message:

"""
This is temporary as long as gdamore/tcell#599 is not
merged. Once that PR is merged, we can revert this.
"""

IMHO, the next steps would be:
* Ask gdamore/tcell to tag a new release so the debian package could be updated
  easily
* Ask lazygit's upstream to adapt back to gdamore/tcell


>   [3] https://github.com/stefanhaller/tcell
>   [4] https://github.com/gdamore/tcell
>   [5] https://tracker.debian.org/pkg/golang-github-gdamore-tcell.v2
>   [6] https://github.com/stefanhaller/tcell/commits/main
[7]: 
https://github.com/stefanhaller/tcell/commit/b7e509067a02e8e0d43bc800293668c4d67f5b19
[8]: https://github.com/gdamore/tcell/pull/599
[9]: 
https://github.com/jesseduffield/lazygit/commit/4aca854b5924b3228f9e69f7bc85dbb1287b4a3e

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1051500: RFS: golang-github-jesseduffield-lazycore and its dependency [ITP]

[Nilesh Patra]

On Sat, Sep 09, 2023 at 03:39:00AM +0530, Jongmin Kim wrote:
> I am looking for a sponsor for two packages:
> 
>   golang-github-samber-lo   #1051506  (lo)
>   golang-github-jesseduffield-lazycore  #1051500  (lazycore)

Uploaded both, thanks!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1039954: ITP: gomuks -- Terminal based Matrix client written in Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: gomuks
  Version : 0.3.0
  Upstream Authors: https://github.com/tulir/gomuks/issues
  URL : https://github.com/tulir/gomuks
* License : AGPL-3+
  Description : Terminal based Matrix client written in Go
 Gomuks is a terminal based Matrix client written in
 Golang which uses mautrix and mauview.


signature.asc
Description: PGP signature

Bug#1039876: ITP: golang-maunium-go-mautrix -- Matrix framework in golang

[Nilesh Patra]

On Thu, 29 Jun 2023 12:33:40 +0530 "Nilesh Patra"  wrote:
>   Version : 0.15.3-1

I have uploaded version 0.11.1-1 to new since that is the version
currently needed by gomuks.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1039892: ITP: golang-go.mau-mauview -- Go TUI library based on tcell

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-go.mau-mauview
  Version : 0.2.1-1
  Upstream Author : Tulir Asokan
* URL : https://github.com/tulir/mauview.git
* License : MPL-2.0
  Programming Lang: Go
  Description : Go TUI library based on tcell
 mauview is a Golang TUI library based on tcell.
 . 
 This package is a dependency of Gomuks

Bug#1039876: ITP: golang-maunium-go-mautrix -- Matrix framework in golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-maunium-go-mautrix
  Version : 0.15.3-1
  Upstream Author : Tulir Asokan
* URL : https://github.com/mautrix/go.git
* License : MPL-2.0
  Programming Lang: Go
  Description : Matrix framework in golang
 Mautrix is a Golang Matrix framework. Used by
 gomuks, go-neb, mautrix-whatsapp and others.

Bug#1039726: ITP: golang-gopkg-vansante-go-ffprobe.v2 -- Library to easily get the ffprobe output of a given file

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-gopkg-vansante-go-ffprobe.v2
  Version : 2.1.1-1
  Upstream Author : Paul van Santen
* URL : https://github.com/vansante/go-ffprobe
* License : Expat
  Programming Lang: Go
  Description : Library to easily get the ffprobe output of a given file 
(library)
 Small library for executing an ffprobe process on a given file and
 getting an easy to use struct representing the returned ffprobe data.
 .
 This is a transitive dep of gomuks.


signature.asc
Description: PGP signature

Bug#1039717: ITP: golang-maunium-go-maulogger -- Simple easy to use logger in go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-maunium-go-maulogger
  Version : 2.4.1-1
  Upstream Author : 2016-2023 Tulir Asokan
* URL : https://github.com/tulir/maulogger.git
* License : MPL-2
  Programming Lang: Go
  Description : Simple easy to use logger in go
 Maulogger is a simple and easy to use logger written
 in golang. Can be used in conjunction with zerolog.
 .
 This is a transitive dep of gomuks.

Bug#1039596: ITP: golang-github-tidwall-sjson -- Set JSON values very quickly in Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-tidwall-sjson
  Version : 1.2.5-1
  Upstream Author : Josh Baker
* URL : https://github.com/tidwall/sjson
* License : Expat
  Programming Lang: Go
  Description : Set JSON values very quickly in Go

 SJSON is a Go package that provides a very fast and simple way to set a
 value in a json document. 

Bug#1039519: ITP: golang-maunium-go-mauflag -- Extendable argument parser for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-maunium-go-mauflag
  Version : 1.0.0-1
  Upstream Author : 2016 Maunium
* URL : https://github.com/tulir/mauflag.git
* License : GPL-3
  Programming Lang: Go
  Description : Extendable argument parser for Golang
 Mauflag is an extendable argument parser for golang that mostly
 follows GNU Program Argument Syntax Conventions.
 .
 This is a transitive dep of gomuks.

Bug#1039057: ITP: golang-go.mau-zeroconfig -- Relatively simple declarative config format for zerolog

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-go.mau-zeroconfig
  Version : 0.1.2-1
  Upstream Author : 2023, Tulir Asokan
* URL : https://github.com/tulir/zeroconfig.git
* License : MPL-2.0
  Programming Lang: Go
  Description : Relatively simple declarative config format for zerolog
 Relatively simple declarative config format for zerolog.
 Meant to be used as YAML, but JSON struct tags are included as well.

 (Transitive) dep of gomuks.

Bug#1039056: ITP: golang-go.mau-zeroconfig -- TODO

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-go.mau-zeroconfig
  Version : 0.1.2-1
  Upstream Author : TODO
* URL : https://github.com/tulir/zeroconfig.git
* License : TODO
  Programming Lang: Go
  Description : Relatively simple declarative config format for zerolog
 Relatively simple declarative config format for zerolog.
 Meant to be used as YAML, but JSON struct tags are included as well.

 (Transitive) dep of gomuks.

Bug#970021: Provisional packaging for Aoache Arrow available

[Nilesh Patra]

On 3/11/23 20:48, Sascha Steinbiss wrote:

I agree. At the moment, though, I must admit I don't really need it anymore 
since the package that I originally needed it for as a dependency (vast) is no 
longer a priority for me. So for me there would be little motivation to keep it 
updated (and also only little insight into version progress and impact of 
changes).


I'm not super keen on it either, but it'd be good to have and we seem to be in 
agreement.


Moreover, it seems like upstream are doing major releases rather frequently [0] 
for which I have no idea of how potentially ABI breaking they are, but I expect 
them to be [1]. That means that there might be a danger of frequent transitions 
if we want to keep up-to-date with upstream's versions.


Agreed.


I have little experience with handling transitions, TBH,


I have been a part of many transitions, so I could probably help a bit at that 
front.


and I am not sure I can dedicate much time to that in the future.


Same, but my understanding is that someone will pick it up if it is important.


If that's OK then I wouldn't mind investing some more time to help make a 
current version in Debian possible, as long as update work can be shared across 
team members.
I'd suggest we disable some features that would require packaging even more 
dependencies though (e.g. aws-sdk-cpp etc.).> What do you think?


Sounds good.


[0]https://arrow.apache.org/release/
[1] https://arrow.apache.org/docs/format/Versioning.html


Thanks,
Nilesh

Bug#970021: Provisional packaging for Aoache Arrow available

[Nilesh Patra]

On 20 December 2021 9:17:40 pm IST, Sascha Steinbiss  wrote:
>TLDR: I have prepared a package to cover as much of Arrow as is possible
>with what we have in Debian, dependency-wise. There is still a review of
>d/copyright missing, and some bundled code might need some extra love or
>removal.
>
>If someone wants to work on this and wants to maintain it for longer,
>feel free to let me know and I might help get it finished. :)
>I just feel I won't be able to keep this updated in time on my own given
>how busy upstream seems to be.

It's quite an old mail but
I can give you a hand with it, however I can't maintain this alone.

I'm seeing this as a dependency in increasing number of packages and it'd be 
good to have this in the archive.

Let me know if we can move fwd with this.


>[1] https://salsa.debian.org/science-team/arrow
>[2] https://lists.debian.org/debian-med/2021/08/msg00066.html
>

--
Best,
Nilesh

Bug#1031862: AdGuardHome packaging (Js and Go)

[Nilesh Patra]

Hi Vit,

I'm member of both the teams, stating my opinion -

On 3/1/23 15:12, Vít Kabele wrote:

I recently started packaging the AdGuardHome DNS server [1]. I published the
ITP to the go-team, as the backend is written in Go, yet now I realised that
the frontend is written in javascript and the packages are installed via npm.


Which packages are you specifically talking about?


1/ To which team should the package belong?


It is upto you. I may suggest going with the golang team as on skimming through 
it,
it mainly looks like having a server-side usage, most of which is implemented 
in golang.


Are there some similar projects?
Where to get inspired with the solution?


Not that I know of, sorry.



2/ Question to the JS team. The frontend comprises of circa 200 npm modules,
out of which only about 50 is already present in Debian repository. Is
it really necessary (I read the manual, yet I want to make sure) to package
all of these separately? [...]


The more, the merrier. However, JS team has provision for embedding smaller JS 
modules, so
you can go ahead with embedding the smaller ones, here's how to do it[2].
Decent-sized node-mdoules, however would need to be separately packaged.

[1]: https://github.com/AdguardTeam/AdGuardHome

[2]: https://wiki.debian.org/Javascript/GroupSourcesTutorial

--
Best,
Nilesh

Bug#1027415: ITP: python-bioframe -- library to enable flexible, scalable operations on genomic interval dataframes

[Nilesh Patra]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Subject: ITP: python-bioframe -- library to enable flexible, scalable 
operations on genomic interval dataframes
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: python-bioframe
  Version : 0.3.3
  Upstream Author : Open2C
* URL : https://github.com/open2c/bioframe
* License : Expat
  Programming Lang: Python
  Description : library to enable flexible, scalable operations on genomic 
interval dataframes
 Building bioframe directly on top of pandas enables immediate access
 to a rich set of dataframe operations. Working in python enables
 rapid visualization (e.g. matplotlib, seaborn) and iteration of
 genomic analyses.
 .
 Bioframe implements a variety of genomic interval operations directly on
 dataframes. Bioframe also includes functions for loading diverse genomic
 data formats, and performing operations on special classes of genomic
 intervals, including chromosome arms and fixed size bins.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-bioframe

Bug#1023727: ITP: r-cran-timechange -- Efficient Manipulation of Date-Times

[Nilesh Patra]

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

Subject: ITP: r-cran-timechange -- Efficient Manipulation of Date-Times
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: r-cran-timechange
  Version : 0.1.1
  Upstream Author : Vitalie Spinu,
* URL : https://cran.r-project.org/package=timechange
* License : GPL-3
  Programming Lang: GNU R
  Description : Efficient Manipulation of Date-Times
 Efficient routines for manipulation of date-time objects while
 accounting for time-zones and daylight saving times. The package includes
 utilities for updating of date-time components (year, month, day etc.),
 modification of time-zones, rounding of date-times, period addition and
 subtraction etc. Parts of the 'CCTZ' source code, released under the Apache
 2.0 License, are included in this package.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-timechange

Bug#1023083: ITP: libquazip1-qt5 -- Qt/C++ wrapper over minizip - Version 1 (Qt5)

[Nilesh Patra]

On 10/30/22 09:38, Ben Westover wrote:

Hello Nilesh,
You're replying to an old message by Filippo; I'm not *trying* to do
anything. I have already explained to Filippo that this is not the
correct way to do that.


Had you simply linked the bug report/alioth-list mails in your original ITP, 
it'd have prevented
this admittedly un-necessary correspondence. It was not clear at all in the 
original
ITP bug as to what the entire situation is, but I understand now.

Thanks for working on it!

--
Best,
Nilesh

Bug#1023083: ITP: libquazip1-qt5 -- Qt/C++ wrapper over minizip - Version 1 (Qt5)

[Nilesh Patra]

On Sun, Oct 30, 2022 at 03:12:18AM +, Ben Westover wrote:
> On 10/29/22 1:20 PM, Filippo Rusconi wrote:
> > On Tue, Sep 13, 2022 at 03:40:13PM +, Ben Westover wrote:
> >> On 9/13/22 8:28 AM, Filippo Rusconi wrote:
>  I'd support any attempt to move the current libquazip[1] away
>  from Debian Med team where it is just by chance since it was a
>  dependency of some of our packages.  It does not make any sense to
>  maintain it inside the Debian Med team and I would love to hand it
>  over.  All maintainers except me do not respond to pings any more
>  and thus can be droped from the list of Uploaders.
> >>>
> >>> I understand that, let's take it away from Debian Med and put it in 
> >>> Debian at
> >>> large. Ben, if you would do the update, then I'd go over it and upload 
> >>> it. That
> >>> would be very good.

If you want to take it out of debian-med team, the right way is to * ask * the
med-team to transfer it somewhere else. What you are trying to do here is 
considered
as a hostile takeover.

> >> As stated above, the existing QuaZip *0.9* package (libquazip) and my
> >> new QuaZip *1.3* package (libquazip1-qt6) are unrelated. While they are
> >> both QuaZip packages, they are separate since QuaZip 0.x and 1.x are
> >> supposed to coexist, much like Qt5 and Qt6. The orphaning of libquazip
> >> is unrelated to my new libquazip1-qt6 being uploaded. My new package is
> >> outside of any team.
> >> The correct procedure here is to orphan libquazip, and anyone who is
> >> interested can adopt it.

Why should the package be orphaned?

> >> Again, my new package libquazip1-qt6 is not
> >> related to the existing libquazip package or the Med Team.

There are already some changes committed to git for version 1.1 in the med team
package. If we happened to miss seeing this ITP, we might have ended up stepping
on your toes.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1017034: ITP: golang-github-marten-seemann-qtls-go1-19 -- Go standard library TLS 1.30 implementation, modified for QUIC (Go-1.19)

[Nilesh Patra]

Hi William,

On Thu, 11 Aug 2022 16:45:23 -0500 William Wilson 
 wrote:
> > * Package name: golang-github-marten-seemann-qtls-go1-19
> >   Version : 0.1.0
> >   Upstream Author : Marten Seemann
> > * URL : https://github.com/marten-seemann/qtls-go1-19
> > * License : BSD-3
> >   Programming Lang: Go
> >   Description : Go standard library TLS 1.30 implementation, modified
> I have packaged this and uploaded it to a PPA:
> https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+sourcefiles/golang-github-marten-seemann-qtls-go1-19/0.1.0-1~ppa1/golang-github-marten-seemann-qtls-go1-19_0.1.0-1~ppa1.dsc
> 
> If someone could sponsor this I'd be very appreciative!

I am sorry to step on your toes, and ended up uploading a new package without 
seeing your existing work, but
I believe this was done by you to get the go transition going to testing.

Would it be OK if I add you in to Uploaders for this package? (Repository on 
salsa)

PS: I also sent a question to the debian go ML pertaining to this package.


-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1018701: ITP: golang-github-marten-seemann-qtls-go1-19 -- Go standard library TLS 1.3 implementation, modified for QUIC (Go-1.19)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-marten-seemann-qtls-go1-19
  Version : 0.1.0-1
  Upstream Author : Marten Seemann
* URL : https://github.com/marten-seemann/qtls-go1-19
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go standard library TLS 1.3 implementation, modified for 
QUIC. For Go 1.19.
 This package is needed to make golang-github-lucas-clemente-quic-go work
 with newer Go version (1.19).

Bug#1016677: ITP: golang-github-templexxx-cpu -- internal/cpu in Go ( add AVX512)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-templexxx-cpu
  Version : 0.0.9-1
  Upstream Author : Temple3x
* URL : https://github.com/templexxx/cpu
* License : BSD-3-clause
  Programming Lang: Go
  Description : Provides CPU related information in Go
 internal/cpu(in Go standard lib) with these detections:
 .
 * AVX512
 * Cache Size
 * Invariant TSC
 .
 It also provides:
 .
 * False sharing range, see X86FalseSharingRange for X86 platform.
 * TSC frequency
 * Name
 * Family & Model

Bug#1016676: ITP: golang-github-templexxx-xorsimd -- XOR code engine in pure Go, more than 270GB/S per core

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-templexxx-xorsimd
  Version : 0.4.1-1
  Upstream Author : Temple3x
* URL : https://github.com/templexxx/xorsimd
* License : Expat
  Programming Lang: Go
  Description : XOR code engine in pure Go, more than 270GB/S per core
 Package xor implements a XOR code engine in pure Go.
 It can deliver more than 270GB/S per core. 

Bug#1016065: ITP: golang-github-shenwei356-unik -- A k-mer serialization package for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-shenwei356-unik
  Version : 5.0.1-1
  Upstream Author : Wei Shen
* URL : https://github.com/shenwei356/unik
* License : Expat
  Programming Lang: Go
  Description : A k-mer serialization package for Golang (library)
 This package provides k-mer serialization methods for the package kmers
 TaxIds of k-mers are optionally saved, while there's no frequency information.
 .
 K-mers (represented in uint64 in RAM ) are serialized in 8-Byte (or less
 Bytes for shorter k-mers in compact format, or much less Bytes for sorted
 k-mers) arrays and optionally compressed in gzip format with extension of
 .unik.

Bug#1016061: ITP: golang-github-shenwei356-kmers -- bit-packed k-mers methods for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-shenwei356-kmers
  Version : 0.1.0-1
  Upstream Author : Wei Shen
* URL : https://github.com/shenwei356/kmers
* License : Expat
  Programming Lang: Go
  Description : bit-packed k-mers methods for Golang (library)
 This package provides manipulations for bit-packed k-mers (k<=32, encoded
 in uint64).

Bug#1014210: ITP: libslow5lib -- library for reading & writing SLOW5 files

[Nilesh Patra]

Package: wnpp
Severity: wishlist

Subject: ITP: libslow5lib -- library for reading & writing SLOW5 files
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: libslow5lib
  Version : 0.5.1
  Upstream Author : Hasindu Gamaarachchi, Sasha Jenner, Hiruna Samarakoon
* URL : https://github.com/hasindu2008/slow5lib
* License : MIT
  Programming Lang: C
  Description : library for reading & writing SLOW5 files
 Slow5lib is a software library for reading & writing SLOW5 files.
 Slow5lib is designed to facilitate use of data in SLOW5 format by third-
 party software packages. Existing packages that read/write data in FAST5
 format can be easily modified to support SLOW5.
 .
 SLOW5 is a new file format for storing signal data from Oxford Nanopore
 Technologies (ONT) devices. SLOW5 was developed to overcome inherent
 limitations in the standard FAST5 signal data format that prevent
 efficient, scalable analysis and cause many headaches for developers.
 SLOW5 can be encoded in human-readable ASCII format, or a more compact
 and efficient binary format (BLOW5) - this is analogous to the seminal
 SAM/BAM format for storing DNA sequence alignments. The BLOW5 binary
 format supports *zlib* (DEFLATE) compression, or other compression
 methods, thereby minimising the data storage footprint while still
 permitting efficient parallel access. Detailed benchmarking experiments
 have shown that SLOW5 format is an order of magnitude faster and
 significantly smaller than FAST5.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/libslow5lib

Bug#1013357: ITP: rust-nom-bibtex -- BibTeX parser using nom

[Nilesh Patra]

On 6/22/22 10:40 PM, Jonas Smedegaard wrote:

* Package name: rust-nom-bibtex
   Version : 0.3.0
   Upstream Author : Charles Vandevoorde 
* URL : https://github.com/charlesvdv/nom-bibtex
* License : Expat
   Programming Lang: Rust
   Description : BibTeX parser using nom

  nom-bibtex is a feature complete *BibTeX* parser using nom.
  It can parse the four differents types of entries
  listed in the BibTeX format description:
   * Preambles which allows to call *LaTeX* command inside your *BibTeX*.
   * Strings which defines abbreviations in a key-value format.
   * Comments.
   * Bibliography entries.

This package is needed by zola (bug#976052).
It will be maintained in the Debian section of Salsa, here:
.



Thanks for your work, Jonas. I was just curious to know if there is a reason
that you are not maintaining it in the rust-team itself (given that there is a 
team)?
BTW, I am not (actively) a part of the team, myself - I might package 
$something rust in near future and
hence the question.

--
Best,
Nilesh
 






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012701: ITP golang-github-cretz-bine -- Go library for accessing and embedding Tor clients and servers

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-cretz-bine
  Version : 0.2.0+ds-1
  Upstream Author : Chad Retz
* URL : https://github.com/cretz/bine
* License : Expat
  Programming Lang: Go
  Description : Go library for accessing and embedding Tor clients and 
servers
 Bine is a Go API for using and controlling Tor. It is similar to Stem
 and has the following features:
 .
  * Full support for the Tor controller API
  * Support for net.Conn and net.Listen style APIs
  * Supports statically compiled Tor to embed Tor into the binary
  * Supports both v2 and v3 onion services
  * Support for embedded control socket in Tor >= 0.3.5 (non-Windows)


signature.asc
Description: PGP signature

Bug#1012673: ITP: golang-github-pion-webrtc.v3 -- Pure Go implementation of the WebRTC API

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-webrtc.v3
  Version : 3.1.41-1
  Upstream Author : Pion
* URL : https://github.com/pion/webrtc
* License : Expat
  Programming Lang: Go
  Description : Pure Go implementation of the WebRTC API (library)
 This package implements WebRTC API in Golang. WebRTC is a free and open-
 source project providing web browsers and mobile applications with real-
 time communication via application programming interfaces.

Bug#1012672: ITP: golang-github-pion-srtp.v2 -- A Go implementation of SRTP

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-srtp.v2
  Version : 2.0.9-1
  Upstream Author : Pion
* URL : https://github.com/pion/srtp
* License : Expat
  Programming Lang: Go
  Description : Go implementation of SRTP (library)
 Library implementing Secure Real-time Transport Protocol (SRTP) in Golang.
 SRTP is used by WebRTC for encrypting media streams being a lighter
 weight option than DTLS.

Bug#1012671: ITP: golang-github-pion-turn.v2 -- Pion TURN, an API for building TURN clients and servers (library)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-turn.v2
  Version : 2.0.8-1
  Upstream Author : Pion
* URL : https://github.com/pion/turn
* License : Expat
  Programming Lang: Go
  Description: Pion TURN, an API for building TURN clients and servers (library)
 Pion TURN is a Go toolkit for building TURN servers and clients.
 pion/turn is an API for building STUN/TURN clients and servers, not a
 binary to deploy and then configure. It may require copying package examples
 and making minor modifications to fit the need, no knowledge of Go is
 required however. 


signature.asc
Description: PGP signature

Bug#1012669: ITP: golang-github-pion-mdns -- Pure Go implementation of Multicast DNS

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-mdns
  Version : 0.0.5-1
  Upstream Author : Pion
* URL : https://github.com/pion/mdns
* License : Expat
  Programming Lang: Go
  Description : Pure Go implementation of Multicast DNS
 Golang mDNS implementation.
 The original user is Pion WebRTC, but is extendable for
 other uses.

Bug#1012668: ITP: golang-github-pion-ice.v2 -- Go implementation of ICE

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-ice.v2
  Version : 2.2.6-1
  Upstream Author : Pion
* URL : https://github.com/pion/ice
* License : Expat
  Programming Lang: Go
  Description: Go implementation of ICE
 Golang library implementing ICE for WebRTC
 Interactive Connectivity Establishment (ICE) is a framework to
 allow user's web browser to connect with peers.
 ICE uses STUN and/or TURN servers to accomplish this.


signature.asc
Description: PGP signature

Bug#1012661: ITP: golang-github-pion-datachannel -- A Go implementation of WebRTC Data Channels

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-datachannel
  Version : 1.5.2-1
  Upstream Author : Pion
* URL : https://github.com/pion/datachannel
* License : Expat
  Programming Lang: Go
  Description: A Go implementation of WebRTC Data Channels
 Golang library implementing WebRTC Data Channels. WebRTC data channel
 lets you send text or binary data over an active connection to a peer

Bug#1012660: ITP: golang-github-pion-dtls -- DTLS 1.2 Server/Client implementation for Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-dtls
  Version : 2.1.5-1
  Upstream Author : Pion
* URL : https://github.com/pion/dtls
* License : Expat
  Programming Lang: Go
  Description : DTLS 1.2 Server/Client implementation for Go
 Native DTLS 1.2vimplementation in the Go programming language.
 .
 This is currently targeting DTLS 1.2, and the most modern/common cipher
 suites. Current features are:
 .
  * DTLS 1.2 Client/Server
  * Key Exchange via ECDHE(curve25519, nistp256, nistp384) and PSK
  * Packet loss and re-ordering is handled during handshaking
  * Key export (RFC 5705 (https://tools.ietf.org/html/rfc5705))
  * Serialization and Resumption of sessions
  * Extended Master Secret extension (RFC 7627)
  * ALPN extension (RFC 7301)

Bug#1012653: ITP: golang-github-pion-sctp -- A Go implementation of SCTP

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-sctp
  Version : 1.8.2-1
  Upstream Author : Pion
* URL : https://github.com/pion/sctp
* License : Expat
  Programming Lang: Go
  Description : A Go implementation of SCTP
 Golang based implementation of Stream Control Transmission Protocol
 .
 SCTP (Stream Control Transmission Protocol) is an IETF standard
 for a transport protocol which enables the reliable, in-order
 transmission of messages while offering congestion control, multi-
 homing, and other features to improve reliability and stability of the
 connection. It's used for sending traditional telephone calls over the
 Internet, but is also used for WebRTC data.

Bug#1012652: ITP: golang-github-pion-transport -- Transport testing for pion

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-trasport
  Version : 0.13.0-1
  Upstream Author : Pion
* URL : https://github.com/pion/transport
* License : Expat
  Programming Lang: Go
  Description : Transport testing for Pion
 Provides multiple plugins for pion/webrtc
 like a VPN layer, eplaydetector providing
 packet replay detection algorithm etc.

Bug#1012650: ITP: golang-github-pion-udp -- A connection-oriented listener over a UDP PacketConn

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-udp
  Version : 0.1.1-1
  Upstream Author : Pion
* URL : https://github.com/pion/udp
* License : Expat
  Programming Lang: Go
  Description : connection-oriented listener over a UDP PacketConn
 This package is used in the pion/DTLS and pion/SCTP
 transport to provide a connection-oriented
 listener over a UDP.

Bug#1012648: ITP: golang-github-pion-interceptor -- Pluggable RTP/RTCP processors for building real time communication

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-interceptor
  Version : 0.1.11-1
  Upstream Author : Pion
* URL : https://github.com/pion/interceptor
* License : Expat
  Programming Lang: Go
  Description : Pluggable RTP/RTCP processors for building real time 
communication
 Interceptor is a framework for building RTP/RTCP communication software.
 This framework defines a interface that each interceptor must satisfy.
 These interceptors are then run sequentially. It also provides
 common interceptors that will be useful for building RTC software.
 .
 This package was built for pion/webrtc but is consumable by anyone. 

Bug#1012645: ITP: golang-github-pion-rtp -- A Go implementation of RTP

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-rtp
  Version : 1.7.5-1
  Upstream Author : Pion
* URL : https://github.com/pion/rtp
* License : Expat
  Programming Lang: Go
  Description : Go implementation of RTP (library)
 Golang based implementation of Real-time Transport Protocol (RTP)
 .
 The Real-time Transport Protocol (RTP), defined in RFC 3550, is an IETF
 standard protocol to enable real-time connectivity for exchanging data
 that needs real-time priority.

Bug#1012646: ITP: golang-github-pion-rtcp -- A Go implementation of RTCP

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-rtcp
  Version : 1.2.9-1
  Upstream Author : Pion
* URL : https://github.com/pion/rtcp
* License : Expat
  Programming Lang: Go
  Description : A Go implementation of RTCP

 See (/DESIGN.md) for an overview of features and future goals.
 .
 Roadmap
 .
 The library is used as a part of our WebRTC implementation. Please refer
 to that roadmap (https://github.com/pion/webrtc/issues/9) to track our
 major milestones.
 .
 Community
 .
 Pion has an active community on the Golang Slack
 (https://invite.slack.golangbridge.org/). Sign up and join the **#pion**
 channel for discussions and support. You can also use Pion mailing list
 (https://groups.google.com/forum/#!forum/pion).
 .
 We are always looking to support **your projects**. Please reach out if
 you have something to build!
 .
 If you need commercial support or don't want to use public methods you
 can contact us at t...@pion.ly (mailto:t...@pion.ly)
 .
 Contributing
 .
 Check out the **contributing wiki** to join the group of amazing people
 making this project possible:
 .
 License
 .
 MIT License - see (/LICENSE) for full text


TODO: perhaps reasoning

Bug#1012644: ITP: golang-github-pion-randutil -- Helper library for cryptographic and mathmatical randoms

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-randutil
  Version : 0.1.0-1
  Upstream Author : Pion
* URL : https://github.com/pion/randutil
* License : Expat
  Programming Lang: Go
  Description: Helper library for cryptographic and mathmatical randoms
 Helper library for cryptographic and mathmatical randoms.
 Used in pion webrtc implementation.

Bug#1012643: ITP: golang-github-pion-logging -- The logging library used by Pion

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-logging
  Version : 0.2.2-1
  Upstream Author : Pion
* URL : https://github.com/pion/logging
* License : Expat
  Programming Lang: Go
  Description : The logging library used by Pion
  The logging library used by Pion (library)
  The library is used as a part of pion WebRTC implementation.
  Provides easy logging for same.

  This is needed for pion webrtc and eventually riseup-vpn.

Bug#1012642: ITP: golang-github-pion-stun -- A Go implementation of STUN

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-stun
  Version : 0.3.4-1
  Upstream Author : Pion
* URL : https://github.com/pion/stun
* License : Expat
  Programming Lang: Go implementation of STUN
 The library is used as a part pion WebRTC implementation.
  Package stun implements Session Traversal Utilities for NAT (STUN)
 [RFC5389] protocol and client with no external
 dependencies and zero allocations in hot paths.
 Client supports automatic requests and retransmissions.

Bug#1012608: ITP: manim-ce -- Animation engine for explanatory math videos

[Nilesh Patra]

Hi Timo,

On 10 June 2022 2:15:25 pm IST, "Timo Röhling"  wrote:
>* Package name: manim-ce
>  Version : 0.15.1
>  Upstream Author : Grant Sanderson, Manim Community Developers
>* URL : https://www.manim.community/
>* License : Expat
>  Programming Lang: Python
>  Description : Animation engine for explanatory math videos
>
>Manim is used to create precise animations programmatically, as demonstrated
>in the videos of 3Blue1Brown. All animations are written as Python code and
>rendered with the manim CLI tool.
> [...]


I have been a huge fan of this software ever since I saw this tooling in 
3Blue-1Brown videos, so thanks for the ITP.

One quick question: since it's a math based package, could you consider 
maintaining it in the math-team umbrella instead?

Let me know what you'd think?


Best,
Nilesh

Bug#1012550: [Pkg-javascript-devel] Bug#1012550: O: node-node-sass -- Wrapper around libsass

[Nilesh Patra]

On 9 June 2022 11:48:58 am IST, Yadd  wrote:
>> Aren't you supposed to orphan it even if you're an uploader?
>> Atleast I have seen several orphan bugs like these.
>> 
>> If not, what's the official procedure to say " I'm not taking care of it 
>> anymore"?
>
>Orphan a package means also change maintainer to qa.debian.org, not staying in 
>the team

Right.
Then what's the official way to indicate that I'm not uploading it anymore?
Is there any other kind of wnpp?
RFA wouldn't be appropriate here either, I suppose.


Best,
Nilesh

Bug#1012550: [Pkg-javascript-devel] Bug#1012550: O: node-node-sass -- Wrapper around libsass

[Nilesh Patra]

On 9 June 2022 9:38:59 am IST, Yadd  wrote:
>On 09/06/2022 05:05, Nilesh Patra wrote:
>> Package: wnpp
>> Severity: normal
>> X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
>> Control: affects -1 src:node-node-sass
>> 
>> I intend to orphan the node-node-sass package.
>> 
>> This was one of the first difficult to do packages that I did, more
>> than 2 years ago.
>> But now I have no personal bandwidth to keep
>> maintaining it, and it is time that I let it go.
>> 
>> The package description is:
>>   Node-sass is a library that provides binding for Node.js to LibSass.
>>   .
>>   LibSass is the C version of the popular stylesheet preprocessor, Sass.
>>   .
>>   It allows you to natively compile .scss files to css at
>>   incredible speed and automatically via a connect middleware.
>>   .
>>   Node.js is an event-based server-side JavaScript engine.
>
>Hi,
>
>this package owns to JS Team, why doing a O here ?

Aren't you supposed to orphan it even if you're an uploader?
Atleast I have seen several orphan bugs like these.

If not, what's the official procedure to say " I'm not taking care of it 
anymore"?

Best,
Nilesh

Bug#1012551: O: node-mermaid -- Markdownish syntax for generating flowcharts,

[Nilesh Patra]

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
Control: affects -1 src:node-mermaid

I intend to orphan the node-mermaid package.
It is a pretty cool package that I packaged approx 2 years ago.
But owing to lack of personal bandwidth, I need to let it go.
It was fun maintaining it, while it lasted.

The package description is:
 sequence diagrams, class diagrams, gantt charts and git graphs.
 .
 It can help visualize flowcharts, diagrams, ganttcharts and git charts can be
 scripted in a markdown syntax, with a varitety of different symbols and chart
 types available. Since the diagram source is text based,
 it can be part of production scipts.
 .
 Automates the diagram generation instead of making it manually.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#1012550: O: node-node-sass -- Wrapper around libsass

[Nilesh Patra]

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
Control: affects -1 src:node-node-sass

I intend to orphan the node-node-sass package.

This was one of the first difficult to do packages that I did, more
than 2 years ago.
But now I have no personal bandwidth to keep
maintaining it, and it is time that I let it go.

The package description is:
 Node-sass is a library that provides binding for Node.js to LibSass.
 .
 LibSass is the C version of the popular stylesheet preprocessor, Sass.
 .
 It allows you to natively compile .scss files to css at
 incredible speed and automatically via a connect middleware.
 .
 Node.js is an event-based server-side JavaScript engine.

--
Best,
Nilesh

Bug#919937: status update

[Nilesh Patra]

On Sun, Jun 05, 2022 at 01:01:54PM +0530, Nilesh Patra wrote:
> > The bug has at least two other bugs blocking it at the moment, but
> > considering how old the last report is, I wouldn't be surprised if
> > upstream introduced new dependencies that need packaging as well.
> 
> Yeah.
> Did you guys start with some prelim/skeleton packaging for this?
> I was wondering if it is hosted on salsa/somewhere else, I could update 
> latest upstream and
> try seeing what extra needs to be added than replicating the effort.

Nevermind.

I have a preliminary packaging ready. Builds, is usable (as far as I tried).
Source package is here[1] -- reviews welcome.

As you might observe, there is a huge vendor/ directory.
Over the next weeks, I will try to package these deps and use debian packaged
stuff instead of vendor, trimming it down as much as I can.

[1]: https://salsa.debian.org/go-team/packages/riseup-vpn

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#919937: status update

[Nilesh Patra]

On Wed, Jun 01, 2022 at 09:10:51AM -0400, Antoine Beaupré wrote:
> > It has been a long time since you sent this email -- is there any progress
> > about it/[...]
> 
> Not as far as I know.

Okay.

> > any known blockers?
> 
> The bug has at least two other bugs blocking it at the moment, but
> considering how old the last report is, I wouldn't be surprised if
> upstream introduced new dependencies that need packaging as well.

Yeah.
Did you guys start with some prelim/skeleton packaging for this?
I was wondering if it is hosted on salsa/somewhere else, I could update latest 
upstream and
try seeing what extra needs to be added than replicating the effort.

> > I would very much like to see riseup-vpn in debian archive, and I would also
> > be willing to help out in getting this packaged.
> 
> As far as I am concerned, please go ahead, but the bug is owned by micah
> so maybe checkin with him first.

@Micah, if you are reading this email, it'd be nice if you could give an ack.

> I would be surprised if he has any
> objection to getting help, that said. :)
> 
> I should also note that I happen to be the Debian maintainer of a few of
> the dependencies that were packaged for this ITP, and I have seriously
> considered orphaning those because I have limited cycles to take care of
> them. So if you want to look into those, feel free to take them over.

I am pretty active in go-packaging team -- I can try if I find those packages
undermaintained. But no committments since I myself maintain 200+ packages ATM 
:)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#919937: status update

[Nilesh Patra]

Hi Micah, Antione,

On Tue, 02 Apr 2019 09:50:55 -0400 micah anderson  wrote:
> Antoine Beaupré  writes:
> 
> > We've processed a bunch of the dependencies for this, and uploaded some
> > to NEW (with related git repos in salsa). Some are not done yet, mostly
> > because their license is unclear.
> 
> The packages indicated in this table as having unclear licenses have had
> that issue resolved, so those packages can be built now.

It has been a long time since you sent this email -- is there any progress
about it/any known blockers?
I would very much like to see riseup-vpn in debian archive, and I would also
be willing to help out in getting this packaged.

Let me know.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1012045: ITP: lamassemble -- Merges overlapping "long" DNA reads into a consensus sequences

[Nilesh Patra]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nil...@posteo.net, nil...@posteo.in, nil...@riseup.net

Subject: ITP: lamassemble -- Merges overlapping "long" DNA reads into a 
consensus sequences
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: lamassemble
  Version : 1.4.2
  Upstream Author : Martin Frith
* URL : https://gitlab.com/mcfrith/lamassemble
* License : Expat
  Programming Lang: Python
  Description : Merges overlapping "long" DNA reads into a consensus 
sequences
 lamassemble merges overlapping "long" DNA reads into a consensus
 sequence (i.e. assembles them). It works OK when the number of reads
 is less than a thousand or so.
 The merging is not always accurate. In particular, if the reads come
 from huge tandem repeats, wrong parts of the reads may get merged.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/lamassemble

Bug#1012044: ITP: dnarrange -- Method to find rearrangements in long DNA reads relative to a genome seq

[Nilesh Patra]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nil...@posteo.in

Subject: ITP: dnarrange -- Method to find rearrangements in long DNA reads 
relative to a genome seq
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: dnarrange
  Version : 1.5.1
  Upstream Author : Martin Frith
* URL : https://github.com/mcfrith/dnarrange
* License : GPL-3+
  Programming Lang: Python
  Description : Method to find rearrangements in long DNA reads relative to 
a genome seq
 This package provides utilities to align the reads
 to the genome, find rearrangements and draw pictures of rearranged groups

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/dnarrange