Bug#1069451: Fixed in latest mmap

[Nilesh Patra]

Control: reassign -1 libmmap-allocator
Control: found -1 0.4.0+git20200122.adbfbe1-1
Control: fixed -1 0.4.0+git20200122.adbfbe1-2
Control: close -1

This is due to mmap not being compiled with t64 flags.
Should be fixed after added cppflags and verified that iitii compiles
in armhf chroot.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1071739: packages.debian.org: Removal of spam domain from download mirror page

[Nilesh Patra]

Package: www.debian.org
Severity: normal
User: www.debian@packages.debian.org
Usertags: packages
X-Debbugs-Cc: sa...@debian.org

Below content is verbatim from 


Hello,

While downloading binary file for a package, on download page [1], under South 
America mirror, there exists http[:]//debian.torredehanoi.org domain. Said 
domain redirected to https[:]//iyfbodn.com which is getting blocked in uBlock 
Origin (due to inclusion in Easylist and Peter Lowe;s Ad and tracking server 
list). URL seems like spam and would request it's removal.

[1]: https://packages.debian.org/sid/all/asn/download

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

[Nilesh Patra]

Hi Julian!

On Sun, May 19, 2024 at 01:48:17PM +0100, Julian Gilbey wrote:
> But here I'd suggest doing the
> opposite: checking for valid build options (and note: this is a check
> for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES).  There is a very
> short list of standard build options: those listed in
> dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse,
> hardening=..., reproducible=..., abi=..., future=..., qa=...,
> optimize=..., sanitize=...) and
> https://wiki.debian.org/BuildProfileSpec: nodoc

I concur. Thanks also to Andrius for +1. If Pollo/Andrius would like to work on
it and/or open a MR, I will be happy to review (and merge).

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

[Nilesh Patra]

Julian Gilbey :
>  I have come across a number of packages with a line in their
>  debian/rules like:
>  
>  ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
>  
>  This should be "nodoc", according to the "nodoc" entry in
>  https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
>  
>  It would be good to check for this error.

This mostly looks like a typo and I am kinda sure that you'd find typos like
this all over many places. I am a bit unsure if checks for this is something we
as a new lintian warning is something that we even need?

Louis-Philippe Véronneau :
> ...
> I've created a patch on Salsa that creates a new Lintian check for this.
> 
> https://salsa.debian.org/lintian/lintian/-/merge_requests/504

And if we do --  I checked the MR and it does not look extensible. If in
future there comes another class of typos, it will result in a new patch of this
kind. Instead, is it possible to have a list of offending terms like this in a
data list and warn the user about them via a lintian warning?

For instance, we have data/fields/obsolete-packages for listing obsolete
packages and showing the user about the obsolete packages and their
replacements. Do you think a similar implementation for this
(data/fields/bad-buildprofiles ?) makes sense?

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 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#1070270: riseup-vpn: client no longer works due to cert verification problem

[Nilesh Patra]

On Wed, May 15, 2024 at 01:01:06PM -0700, Matt Taggart wrote:
> 
> On 5/10/24 07:26, Nilesh Patra wrote:
> 
> > Going for an upload to unstable followed by an s-p-u.
> > 
> > > > [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
> 
> I was finally able to install 0.21.11+ds1-5+deb12u1 from the above on my
> bookworm test system and it fixed things and the vpn is working again!
> An upload to s-p-u would be great.

Uploaded already to s-p-u filed https://bugs.debian.org/1070856 for approval.
Also uploaded new version to backports-new.

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#1070410: golang-github-pion-webrtc.v3 accesses the internet during build

[Nilesh Patra]

On Sat, May 11, 2024 at 02:18:40PM +0200, Santiago Vila wrote:
> Hi.
> 
> Have you tried tcpdump while the tests are running?
> 
> I see a DNS query for stun.l.google.com, which is also
> somewhere in the code.

That is only for peer connection tests. A bunch of other tests should not fail
imho.

> I believe DNS queries count
> as "internet access" and are not allowed.

Uhm, fine. For now I will disable the testsuite and upload, don't have more time
to investigate. Thanks for helping me out.

> 
> Thanks.
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070410: golang-github-pion-webrtc.v3 accesses the internet during build

[Nilesh Patra]

Quoting Jochen Sprickerhof :
>  golang-github-pion-webrtc.v3 attempts network access during build.
>  This is forbidden by Policy 4.9:

Are you sure about this? I don't think so.

I built this in an offline environment w/o any internet access and it builds 
just
OK. Furthermore I compared the logs with the one in buildd and I did not see
anything unusual.

>For packages in the main archive, required targets must not attempt
>network access, except, via the loopback interface, to services on the
>build host that have been started by the build.
>  
>  This can be tested with the sbuild unshare backend:

I tried building this in an offline setting, didn't use unshare backend. Does
the latter do anything differently?
 
>  === NAME  TestDataChannelParamters_Go
>  util.go:41: Unexpected routines on test end:
>  goroutine 34 [select]:
>  
> github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).loop(0xc240a0,
>  {0x9f4b80, 0xc3ec30})
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:139
>  +0x12d
>  created by 
> github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).BindRTCPWriter 
> in goroutine 16
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:74
>  +0x115
>  
>  goroutine 35 [select]:
>  
> github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).loop(0xc0001303c0,
>  {0x9f4b80, 0xc3ec30})
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:97
>  +0x19c
>  created by 
> github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).BindRTCPWriter 
> in goroutine 16
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:86
>  +0x115
>  
>  goroutine 36 [select]:
>  
> github.com/pion/interceptor/pkg/report.(*SenderInterceptor).loop(0xc000130420,
>  {0x9f4b80, 0xc3ec30})
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:98
>  +0x19c
>  created by 
> github.com/pion/interceptor/pkg/report.(*SenderInterceptor).BindRTCPWriter in 
> goroutine 16
>  
> /<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:87
>  +0x115

I don't see any of these failures either. Please comment?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070768: bpfcc: ftbfs on ppc64el

[Nilesh Patra]

Quoting Luca Boccassi:
>  Source: bpfcc
>  Version: 0.29.1+ds-1
>  Severity: serious
>  Tags: ftbfs
>  
>  Hi,
>  
>  bpfcc has been failing to build on ppc64el for a long time, and this is
>  keeping it out of testing.
>  
>  If you don't have time to fix it, could you please consider at least a
>  quick upload to remove ppc64el from the list of architectures, so that
>  it can go back to testing?
>  
>  Thanks!
>  

Vasudev, Ritesh, this bug is causing a bunch of packages getting removed from
testing (bpfcc and transitive reverse depends). Can I ask you to please take
care of this, maybe dropping ppc64el altogether if it is not feasible to fix?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070856: bookworm-pu: package riseup-vpn/0.21.11+ds1-5+deb12u1

[Nilesh Patra]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: riseup-...@packages.debian.org, nil...@debian.org
Control: affects -1 + src:riseup-vpn
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
The bug got introduced due to a change in the external services that riseup-vpn
interacts with (riseup's servers) and failing to identify their letsencrypt 
certs.

Full details at Bug#1070270

[ Impact ]
The package is rendered unusable and the user will not be able to use riseup-vpn
and connect to the vpn.

[ Tests ]
Tried this on a fresh stable VM with multiple different angles.
This has also been tried on a stable user's machine and the problem is verified
to have been fixed.

[ Risks ]
This is a leaf package and the changes are fairly minimal. Very low risk to 
stable.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
 Add patch to fixup client verification problems with
 riseup-vpn which renders the package useless otherwise.
 At the moment, the current code is unable to identify the
 letsencrypt certs. Used a systempool for the same and create
 a newcertpool as a fallback. Also added a Depends in d/control
 for ca-certificates for the same reason.

[ Other info ]
Since this is a leaf package and the breakage is due to external services, this 
may be a
candidate for stable-updates suite as per 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-the-stable-updates-suite

> Examples of circumstances in which the upload may qualify for such treatment 
> are:
> ...
> Uploads to stable-updates should target their suite name in the changelog as 
> usual, e.g. bookworm.

Since I was confident that this should be accepted, I did a (source-only) 
dput/upload.
diff -Nru riseup-vpn-0.21.11+ds1/debian/changelog 
riseup-vpn-0.21.11+ds1/debian/changelog
--- riseup-vpn-0.21.11+ds1/debian/changelog 2023-03-09 09:51:22.0 
+0530
+++ riseup-vpn-0.21.11+ds1/debian/changelog 2024-05-10 20:13:39.0 
+0530
@@ -1,3 +1,15 @@
+riseup-vpn (0.21.11+ds1-5+deb12u1) bookworm; urgency=medium
+
+  * Add patch to fixup client verification problems with
+riseup-vpn which renders the package useless otherwise.
+At the moment, the current code is unable to identify the
+letsencrypt certs. Used a systempool for the same and create
+a newcertpool as a fallback. Also added a Depends in d/control
+for ca-certificates for the same reason.
+(Closes: #1070270)
+
+ -- Nilesh Patra   Fri, 10 May 2024 20:13:39 +0530
+
 riseup-vpn (0.21.11+ds1-5) unstable; urgency=medium
 
   * Add procps, iproute2 and iptables to Depends (Closes: #1031905)
diff -Nru riseup-vpn-0.21.11+ds1/debian/control 
riseup-vpn-0.21.11+ds1/debian/control
--- riseup-vpn-0.21.11+ds1/debian/control   2023-03-09 09:51:22.0 
+0530
+++ riseup-vpn-0.21.11+ds1/debian/control   2024-05-10 20:13:39.0 
+0530
@@ -52,6 +52,7 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
+ ca-certificates,
  iproute2,
  iptables,
  pkexec,
diff -Nru riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch 
riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
--- riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
1970-01-01 05:30:00.0 +0530
+++ riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
2024-05-10 20:13:39.0 +0530
@@ -0,0 +1,27 @@
+From 14cf64b10a97c29688f252a7d9d3481c8484aa1d Mon Sep 17 00:00:00 2001
+From: max b 
+Date: Wed, 8 Mar 2023 12:41:45 -0800
+Subject: [PATCH] Add system certs to bonafide
+
+lilypad/float is now using letsencrypt certs for vpnweb so instead of
+instantiating an empty cert pool, we can just use the system pool and
+then add the manually configured cert for backwards compatibility.
+---
+ pkg/vpn/bonafide/bonafide.go | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/pkg/vpn/bonafide/bonafide.go
 b/pkg/vpn/bonafide/bonafide.go
+@@ -94,7 +94,11 @@
+ 
+ // New Bonafide: Initializes a Bonafide object. By default, no Credentials 
are passed.
+ func New() *Bonafide {
+-  certs := x509.NewCertPool()
++  certs, err := x509.SystemCertPool()
++  if err != nil {
++  log.Println("Error loading SystemCertPool, falling back to 
empty pool")
++  certs = x509.NewCertPool()
++  }
+   certs.AppendCertsFromPEM(config.CaCert)
+   client := {
+   Transport: {
diff -Nru riseup-vpn-0.21.11+ds1/debian/patches/series 
riseup-vpn-0.21.11+ds1/debian/patches/series
--- riseup-vpn-0.21.11+ds1/debian/patches/series2023-02-26 
02:39:10.0 +0530
+++ riseup-vpn-0.21.11+ds1/debian/patches/series2024-05-10 
20:13:39.000

Bug#1070270: riseup-vpn: client no longer works due to cert verification problem

[Nilesh Patra]

On Sun, May 05, 2024 at 09:47:40PM +0530, Nilesh Patra wrote:
> On Sat, May 04, 2024 at 08:59:19PM +0530, Nilesh Patra wrote:
> > Hi Matt,
> > 
> > Quoting Matt Taggart:
> > >  Package: riseup-vpn
> > >  Version: 0.21.11+ds1-5+b1
> > >  Severity: grave
> > >  
> > >  When attempting to run the bookworm riseup-vpn package, it fails to 
> > >  connect to riseup's servers and gives the following output:
> > >  
> > >  2024/05/01 18:21:23 Error fetching eip v3 
> > >  json:https://api.black.riseup.net/3/config/eip-service.json
> > >  
> > >  My understanding is that this is due to the package failing to be able 
> > >  to verify the current LetsEncrypt cert that host is using. More details 
> > > at
> > >  
> > >  https://0xacab.org/leap/bitmask-vpn/-/issues/768
> > >  
> > >  (supposedly the current upstream snap has this fixed, but I haven't 
> > >  tried it)
> > >  
> > >  As this breaks what the package is supposed to do (at least when using 
> > >  riseup as provider, maybe there is a way to point it elsewhere?) I think 
> > >  this is grave. Also I think it might be a good candidate for being fixed 
> > >  in a stable release update.
> > 
> > If I am not mistaken, as per the said, issue, it is fixed in the commit
> > referenced here, right?
> > 
> > 
> > https://0xacab.org/leap/bitmask-vpn/-/commit/14cf64b10a97c29688f252a7d9d3481c8484aa1d
> > 
> > I tried this in my testing system and it seems I am able to connect to the 
> > VPN
> > with this patch applied. Can you confirm?
> 
> I tried with this commit using my stable `.deb` in a fresh stable VM and it
> seems things are working.

I got more extensive testing done. This definitely fixes the issue as it helps
verify the letsencrypt certificate.

> > Consequently, I also did some work to cherry-pick this and prepare a 
> > stable-p-u
> > upload (not yet uploaded, will do after confirmation) and pushed my changes
> > at[1]. I have also compiled the `.deb` for stable and it is ready to be
> > consumed[2]. Do you think you could ask someone to check the same?
> > 
> > Other than that, I also tried to update the package in unstable to the 
> > latest
> > version to fixup this properly. I was able to build it, pushed my changes
> > here[3] and the `.deb` is available here[4]. Again, if you/someone else 
> > could
> > try this, it'd be great. It is working for me on my debian/testing system.
> 
> I asked a friend to check on their testing system and it seems to be working 
> as
> well. I will proceed to upload these in a week or so. Until then I am awaiting
> your response.

OK, so now the time is up and I've got some spare time now - I am going ahead
with an upload. This look fine and the package works.

> > I would have attemped the update much sooner but unfortunately an update 
> > with
> > 0xacab's gitlab broke my d/watch file and I did not notice a new version is 
> > out
> > there sooner.
> > 
> > I was thinking to go ahead with an upload, but there are a few things that I
> > would like to clarify before I do so (btw thanks to the maintainers for
> > committing a patch to use with qt6.4):

To be clear: these questions do not apply to the stable update. Only to the
unstable one.

> > 1. Why is the default provider set to "provider = bitmask" in
> > providers/vendor.conf? This leads to building the binary called bitmask-vpn
> > instead of riseup-vpn. Is there a thought of changing the binary name?
> > 
> > In current stage it points to just dummy APIs and hence I overrode it in 
> > d/rules
> > to build riseup-vpn instead.

I am keeping this as is.

> > 2. In the vendor/gitlab.com/yawning/obfs4.git/ package, there are 3 license.
> > BSD-2-Clause, BSD-3-Clause and also GPL-3 for
> > vendor/gitlab.com/yawning/obfs4.git/internal/x25519ell2/x25519ell2.go - so 
> > what
> > exactly is the exact license? Is it redistributable under all the three? (I
> > don't think so?)

I found a comment from yawning and added the internal/* under GPL.

Going for an upload to unstable followed by an s-p-u.

> > [1]: 
> > https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/bookworm-pu?ref_type=heads
> > [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
> > [3]: 
> > https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/sid?ref_type=heads
> > [4]: https://people.debian.org/~nilesh/riseup-vpn-0.24.5/
[5]: https://gitlab.com/yawning/obfs4/-/issues/5

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070270: riseup-vpn: client no longer works due to cert verification problem

[Nilesh Patra]

On Sat, May 04, 2024 at 08:59:19PM +0530, Nilesh Patra wrote:
> Hi Matt,
> 
> Quoting Matt Taggart:
> >  Package: riseup-vpn
> >  Version: 0.21.11+ds1-5+b1
> >  Severity: grave
> >  
> >  When attempting to run the bookworm riseup-vpn package, it fails to 
> >  connect to riseup's servers and gives the following output:
> >  
> >  2024/05/01 18:21:23 Error fetching eip v3 
> >  json:https://api.black.riseup.net/3/config/eip-service.json
> >  
> >  My understanding is that this is due to the package failing to be able 
> >  to verify the current LetsEncrypt cert that host is using. More details at
> >  
> >  https://0xacab.org/leap/bitmask-vpn/-/issues/768
> >  
> >  (supposedly the current upstream snap has this fixed, but I haven't 
> >  tried it)
> >  
> >  As this breaks what the package is supposed to do (at least when using 
> >  riseup as provider, maybe there is a way to point it elsewhere?) I think 
> >  this is grave. Also I think it might be a good candidate for being fixed 
> >  in a stable release update.
> 
> If I am not mistaken, as per the said, issue, it is fixed in the commit
> referenced here, right?
> 
>   
> https://0xacab.org/leap/bitmask-vpn/-/commit/14cf64b10a97c29688f252a7d9d3481c8484aa1d
> 
> I tried this in my testing system and it seems I am able to connect to the VPN
> with this patch applied. Can you confirm?

I tried with this commit using my stable `.deb` in a fresh stable VM and it
seems things are working.

> Consequently, I also did some work to cherry-pick this and prepare a 
> stable-p-u
> upload (not yet uploaded, will do after confirmation) and pushed my changes
> at[1]. I have also compiled the `.deb` for stable and it is ready to be
> consumed[2]. Do you think you could ask someone to check the same?
> 
> Other than that, I also tried to update the package in unstable to the latest
> version to fixup this properly. I was able to build it, pushed my changes
> here[3] and the `.deb` is available here[4]. Again, if you/someone else could
> try this, it'd be great. It is working for me on my debian/testing system.

I asked a friend to check on their testing system and it seems to be working as
well. I will proceed to upload these in a week or so. Until then I am awaiting
your response.

> I would have attemped the update much sooner but unfortunately an update with
> 0xacab's gitlab broke my d/watch file and I did not notice a new version is 
> out
> there sooner.
> 
> I was thinking to go ahead with an upload, but there are a few things that I
> would like to clarify before I do so (btw thanks to the maintainers for
> committing a patch to use with qt6.4):
> 
> 1. Why is the default provider set to "provider = bitmask" in
> providers/vendor.conf? This leads to building the binary called bitmask-vpn
> instead of riseup-vpn. Is there a thought of changing the binary name?
> 
> In current stage it points to just dummy APIs and hence I overrode it in 
> d/rules
> to build riseup-vpn instead.
> 
> 2. In the vendor/gitlab.com/yawning/obfs4.git/ package, there are 3 license.
> BSD-2-Clause, BSD-3-Clause and also GPL-3 for
> vendor/gitlab.com/yawning/obfs4.git/internal/x25519ell2/x25519ell2.go - so 
> what
> exactly is the exact license? Is it redistributable under all the three? (I
> don't think so?)
> 
> [1]: 
> https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/bookworm-pu?ref_type=heads
> [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
> [3]: 
> https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/sid?ref_type=heads
> [4]: https://people.debian.org/~nilesh/riseup-vpn-0.24.5/
> 
> Best,
> Nilesh


Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070270: riseup-vpn: client no longer works due to cert verification problem

[Nilesh Patra]

Hi Matt,

Quoting Matt Taggart:
>  Package: riseup-vpn
>  Version: 0.21.11+ds1-5+b1
>  Severity: grave
>  
>  When attempting to run the bookworm riseup-vpn package, it fails to 
>  connect to riseup's servers and gives the following output:
>  
>  2024/05/01 18:21:23 Error fetching eip v3 
>  json:https://api.black.riseup.net/3/config/eip-service.json
>  
>  My understanding is that this is due to the package failing to be able 
>  to verify the current LetsEncrypt cert that host is using. More details at
>  
>  https://0xacab.org/leap/bitmask-vpn/-/issues/768
>  
>  (supposedly the current upstream snap has this fixed, but I haven't 
>  tried it)
>  
>  As this breaks what the package is supposed to do (at least when using 
>  riseup as provider, maybe there is a way to point it elsewhere?) I think 
>  this is grave. Also I think it might be a good candidate for being fixed 
>  in a stable release update.

If I am not mistaken, as per the said, issue, it is fixed in the commit
referenced here, right?


https://0xacab.org/leap/bitmask-vpn/-/commit/14cf64b10a97c29688f252a7d9d3481c8484aa1d

I tried this in my testing system and it seems I am able to connect to the VPN
with this patch applied. Can you confirm?

Consequently, I also did some work to cherry-pick this and prepare a stable-p-u
upload (not yet uploaded, will do after confirmation) and pushed my changes
at[1]. I have also compiled the `.deb` for stable and it is ready to be
consumed[2]. Do you think you could ask someone to check the same?

Other than that, I also tried to update the package in unstable to the latest
version to fixup this properly. I was able to build it, pushed my changes
here[3] and the `.deb` is available here[4]. Again, if you/someone else could
try this, it'd be great. It is working for me on my debian/testing system.

I would have attemped the update much sooner but unfortunately an update with
0xacab's gitlab broke my d/watch file and I did not notice a new version is out
there sooner.

I was thinking to go ahead with an upload, but there are a few things that I
would like to clarify before I do so (btw thanks to the maintainers for
committing a patch to use with qt6.4):

1. Why is the default provider set to "provider = bitmask" in
providers/vendor.conf? This leads to building the binary called bitmask-vpn
instead of riseup-vpn. Is there a thought of changing the binary name?

In current stage it points to just dummy APIs and hence I overrode it in d/rules
to build riseup-vpn instead.

2. In the vendor/gitlab.com/yawning/obfs4.git/ package, there are 3 license.
BSD-2-Clause, BSD-3-Clause and also GPL-3 for
vendor/gitlab.com/yawning/obfs4.git/internal/x25519ell2/x25519ell2.go - so what
exactly is the exact license? Is it redistributable under all the three? (I
don't think so?)

[1]: 
https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/bookworm-pu?ref_type=heads
[2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
[3]: 
https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/sid?ref_type=heads
[4]: https://people.debian.org/~nilesh/riseup-vpn-0.24.5/

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1069740: kitty: incorrectly acts like mouse button is pressed

[Nilesh Patra]

Hi Russell,

On Wed, Apr 24, 2024 at 07:31:02AM +1000, Russell Coker wrote:
> Package: kitty
> Version: 0.33.1-1
> Severity: normal
> 
> I routinely run kitty with between 4 and 16 terminals in one kitty window.
> When moving the mouse across the screen it's a common occurance (multiple
> times per hour) for one terminal to act like the mouse button is pressed
> and try to make it a swipe to select operation.
> 
> This happens on my laptop running Unstable and my workstation running
> Bookworm.

As per upstream discussion this should be fixed in the latest release which I
will dpu ts shortly. Hence I am marking it in the d/ch as such. Feel free to
re-open the bug report if the issue persists.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1069062: golang-github-disintegration-imaging: CVE-2023-36308

[Nilesh Patra]

Hi Security team,

There's a third party patch for this CVE[2], and at least testing locally with 
the
PoC in[1] seems to mitigate the issue. Do you think this is OK to pick and
upload?

Maytham Alsudany wrote:
>  Hi Anthony,
>  
>  As you are the uploader for golang-github-disintegration-imaging, I'd like 
> your input on CVE-2023-
>  36308 and approval for the proposed patch, before any new upload is made.
>  
>  There has been a failed attempt to inform upstream of this issue at [1], and 
> their last commit was 4
>  years ago, so we're not likely to see a fix from upstream.
>  
>  Instead, I've found a (very minimal) third-party patch at [2] which fixes 
> this issue, and have
>  pushed it to the Salsa repo[3].
>  
>  The original security bug report is attached below.
>  
>  Kind regards,
>  Maytham
>  
>  On Mon, 15 Apr 2024 21:30:20 +0300 Maytham Alsudany 
>  wrote:
> > Package: golang-github-disintegration-imaging
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: normal
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for 
> > golang-github-disintegration-imaging.
> > 
> > CVE-2023-36308[0]:
> > | disintegration Imaging 1.6.2 allows attackers to cause a panic
> > | (because of an integer index out of range during a Grayscale call)
> > | via a crafted TIFF file to the scan function of scanner.go. NOTE: it
> > | is unclear whether there are common use cases in which this panic
> > | could have any security consequence
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2023-36308
> > https://www.cve.org/CVERecord?id=CVE-2023-36308
> > 
> > Please adjust the affected versions in the BTS as needed.
> > 
> > Kind regards,
> > Maytham
>  
>  [1]: https://github.com/disintegration/imaging/issues/165
>  [2]: https://github.com/kovidgoyal/imaging/commit/68f6e7d
>  [3]: 
> https://salsa.debian.org/go-team/packages/golang-github-disintegration-imaging/-/commit/24e17d9e
>

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches

[Nilesh Patra]

On Sat, Apr 20, 2024 at 02:57:28PM +, Thorsten Glaser wrote:
> >Right. AFAICS, lintian spews that warning because the header in that patch in
> >incomplete. It also needs a "From" and "Subject" (which can be same as commit
> 
> this is not entirely correct.
> 
> The full patch header is:
> 
> Description: fix typeset -p confusion between empty and unset
> Origin: commit:10065BC69BE555D6721
> 
> Description is the standard name for Subject (the same way
> Author is the standard DEP 3 name for From), and it’s present,
> and when Origin indicates an upstream commit (as shown here),
> Author does not need to be present, per DEP 3.

OK, makes sense to me -- thank you!

I dived a little deeper and it seems lintian is checking
whether or not the Origin field's first value before comma is a valid value
(upstream or vendor). However, in your header, you did not specify such a field.
As per dep3, it is optional and hence lintian should not do stringent checks on
this field i.e. assuming that it will have a first paramater of "upsteam, foo"
or "backports, foo".

I've opened an MR https://salsa.debian.org/lintian/lintian/-/merge_requests/499
which is potentially fixing this, and based on local testing
this does not cause regressions, and does not spew that warning/info with your
header as well. However, the fix may still not be proper -- not a perl champ.

I'll leave the review for lintian maintainers.

> bye,
> //mirabilos
> -- 
> If Harry Potter gets a splitting headache in his scar
> when he’s near Tom Riddle (aka Voldemort),
> does Tom get pain in the arse when Harry is near him?
>   -- me, wondering why it’s not Jerry Potter………
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches

[Nilesh Patra]

Hi Thorsten,

Quoting mirabilos:
> (at least bookworm’s) lintian complains about…
> I: mksh source: patch-not-forwarded-upstream 
> [debian/patches/typeset-p-fix.diff]
> … for patches whose DEP 3 metadata clearly state they are a
> cherry-pick or backport from upstream.
>
> Here (cherry-pick):
>
> Origin: commit:10065BC69BE555D6721
>
> DEP 3 says the Forwarded header is only applicable for
> patches that don’t originate upstream.

Right. AFAICS, lintian spews that warning because the header in that patch in
incomplete. It also needs a "From" and "Subject" (which can be same as commit
message) and something that's also specified in the dep3 protocol while
cherry-picking patch from upstream. https://dep-team.pages.debian.net/deps/dep3/

If you add the "From" and "Subject" field, this should work. If you can confirm
the same, we could close this bug.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1069192: Autopkgtest failure: missing dependency on python3-pytz

[Nilesh Patra]

I will NMU this in a week or so if I see no activity. This package has been
going through in-attention for a while.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1069192: Autopkgtest failure: missing dependency on python3-pytz

[Nilesh Patra]

Source: lektor
Version: 3.3.7-2
Severity: serious
X-Debbugs-Cc: jer...@riseup.net

Hi,

lektor fails its autopkgtests with babel in unstable with:

67s autopkgtest [16:15:09]: test upstream: [---
 67s /usr/lib/python3/dist-packages/_pytest/config/__init__.py:331: 
PluggyTeardownRaisedWarning: A plugin raised an exception during an old-style 
hookwrapper teardown.
 67s Plugin: helpconfig, Hook: pytest_cmdline_parse
 67s ConftestImportFailure: ModuleNotFoundError: No module named 'pytz' (from 
/tmp/autopkgtest-lxc.jih8d3_e/downtmp/autopkgtest_tmp/tests/conftest.py)
 67s For more information see 
https://pluggy.readthedocs.io/en/stable/api_reference.html#pluggy.PluggyTeardownRaisedWarning
 67s   config = pluginmanager.hook.pytest_cmdline_parse(
 67s ImportError while loading conftest 
'/tmp/autopkgtest-lxc.jih8d3_e/downtmp/autopkgtest_tmp/tests/conftest.py'.
 67s tests/conftest.py:11: in 
 67s from lektor.builder import Builder
 67s /usr/lib/python3/dist-packages/lektor/builder.py:15: in 
 67s from lektor.build_programs import builtin_build_programs
 67s /usr/lib/python3/dist-packages/lektor/build_programs.py:8: in 
 67s from lektor.db import Attachment
 67s /usr/lib/python3/dist-packages/lektor/db.py:28: in 
 67s from lektor.datamodel import load_datamodels
 67s /usr/lib/python3/dist-packages/lektor/datamodel.py:13: in 
 67s from lektor.types import builtin_types
 67s /usr/lib/python3/dist-packages/lektor/types/__init__.py:13: in 
 67s from lektor.types.primitives import BooleanType
 67s /usr/lib/python3/dist-packages/lektor/types/primitives.py:6: in 
 67s from pytz import FixedOffset
 67s E   ModuleNotFoundError: No module named 'pytz'
 68s autopkgtest [16:15:10]: test upstream: ---]

https://ci.debian.net/packages/l/lektor/testing/amd64/45501555/

It seems to use pytz in

lektor/types/primitives.py:from pytz import FixedOffset

and thus should have a dep on pytz regardless.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1068065: RM: quorum [armhf i386 armel] -- ROM; cannot build on 32-bit archs due to missing builddeps

[Nilesh Patra]

retitle 1068065 RM: quorum [armhf i386 armel] -- ROM; cannot build on 32-bit 
archs due to missing builddeps
reassign 1068065 ftp.debian.org
user ftp.debian@packages.debian.org
usertags 1068065 remove
stop

Hi,

quorum builddeps on jellyfish which is not present on 32-bit archs any
longer[1].
There is already some concensus in -med team to prune 32-bit arch support for
end-user applications (like quorum) if it is not straightfwd to maintain the
support. It should make it to policy soonish.

[1]: 
https://tracker.debian.org/news/1513470/accepted-jellyfish-231-3-source-into-unstable/

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf

[Nilesh Patra]

Control: severity -1 wishlist

Hi,

maude has been -rm'ed on 32-bit archs as per 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068766
So this issue is now moot and I am downgrading the severity.

On Thu, Apr 11, 2024 at 07:53:08AM +0200, Andreas Tille wrote:
> Hi,
> 
> Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker:
> > I like that solution since I believe there are 64-bit platforms where long
> > is 32-bits. I've updated my development version thus:
> > 
> >   //
> >   //    timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't
> > yet have support
> >   //    for long long which is a problem on platforms where long is less
> > than 8 bytes.
> >   //
> > #if SIZEOF_LONG < 8
> >   double seconds = timeValue.tv_sec;
> > #else
> >   long seconds = timeValue.tv_sec;
> > #endif
> >   mpz_class nanoSeconds(seconds);
> 
> Sounds like some working solution.  It would help if you could tag a new
> released to enable us fetching a fresh tarball incorporatinig this
> change.
>  
> > Of course I expect to drop support for 32-bit before 2038 - certainly when
> > one our dependencies drops support. But I've gotten a bug report for
> > building Maude on a Raspberry Pi.
> 
> Raspian is based on Debian and if the 32bit ARM architectures fail here
> Raspian people have a problem.
> 
> Kind regards
>Andreas. 
> 
> -- 
> https://fam-tille.de
> 
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#1068766: RM: maude [i386 armhf armel] -- ROM; Unsuitable for release on 32-bit archs

[Nilesh Patra]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ma...@packages.debian.org, ti...@debian.org, 
sramac...@debian.org, debian-...@lists.debian.org
Control: affects -1 + src:maude
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

maude FTBFS on 32-bit archs and the temporary fix will explode at some point
due to Y2038. This is due to gmp not having proper support for 32-bits.

As was a concensus on -med, there's some agreement to remove 32-bit support for
end-user applications since no-one uses med packages on these archs[1].

The maintainer/uploader of maude also agreed to the removal on 32-bit archs for 
this
package in[2]

[1]: https://lists.debian.org/debian-med/2024/03/msg00032.html
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957#46

Bug#1067957: Maude fails to build on armhf

[Nilesh Patra]

On Sun, Apr 07, 2024 at 07:45:33PM +0530, Nilesh Patra wrote:
> Hi,
> 
> Maude fails to build on armhf/arm32 arch with:
> 
> In file included from timeManagerSymbol.cc:64:
> timeActions.cc: In member function ‘void 
> TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*, 
> ObjectSystemRewritingContext&)’:
> timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is 
> ambiguous
>43 |   mpz_class nanoSeconds(timeValue.tv_sec);
>   | ^
> In file included from ../../src/BuiltIn/succSymbol.hh:28,
>  from timeManagerSymbol.cc:53:
> /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], 
> __mpz_struct [1]>::__gmp_expr(double)’
>  1646 |   __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
>   |   ^~
> /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], 
> __mpz_struct [1]>::__gmp_expr(float)’
> 
> Full long here: 
> https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0
> And Debian bug report here: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957
> 
> Would be great if you have the cycles to look into it.

This patch fixes the issue at hand but I am unsure if it is sensible to apply
it.

diff --git a/src/ObjectSystem/timeActions.cc b/src/ObjectSystem/timeActions.cc
index 77395aa..63aa028 100644
--- a/src/ObjectSystem/timeActions.cc
+++ b/src/ObjectSystem/timeActions.cc
@@ -40,7 +40,7 @@ TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode* message, 
ObjectSystemRewriting
   DebugSave(r, clock_gettime(CLOCK_REALTIME, ));
   Assert(r == 0, "clock_gettime() failed: " << strerror(errno));
 
-  mpz_class nanoSeconds(timeValue.tv_sec);
+  mpz_class nanoSeconds(static_cast(timeValue.tv_sec));
   nanoSeconds *= BILLION;
   nanoSeconds += timeValue.tv_nsec;
 

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#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists

[Nilesh Patra]

On 4 April 2024 2:28:07 am IST, Santiago Vila  wrote:
>Hi. I've just realized that (as a member of Debian Med)
>I could fix this myself.
>
>Nilesh: Would it help if I do a "team upload" to fix this?
>(Using the proposed patch)
>
>Or would you prefer to fix it yourself?

Just go ahead with a fix. I don't have much time these days. Please also drop 
me from uploaders field for this package won't have time to maintain this.

>Thanks.

Thank you very much for helping out!

Bug#1067410: golang-github-go-jose-go-jose-dev: ftbfs on i386 and mips64el due to timeout of test case

[Nilesh Patra]

> The 4.0.1-2 still has timeout on test issue, see:
> https://buildd.debian.org/status/logs.php?pkg=golang-github-go-jose-go-jose=i386
>
> https://buildd.debian.org/status/logs.php?pkg=golang-github-go-jose-go-jose=mips64el
>
> So open this to trace it again.
> ...
> golang-github-go-jose-go-jose (4.0.1-3) unstable; urgency=medium
> .
>   * Skip one test on some architectures accurately. (Closes: #1067410)

You could instead increase the timeout too with:

override_dh_auto_test:
dh_auto_test -- -timeout=1h

Unless the tests run on those archs forever.

Best,
Nilesh


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#1064824: node-d3: fails to export map and other functions

[Nilesh Patra]

On Mon, Mar 04, 2024 at 09:18:01PM +, Julian Gilbey wrote:
> index.js → dist/d3.js...
> (!) Conflicting re-exports
> "index.js" re-exports "map" from both 
> "../../../usr/share/nodejs/d3-array/src/index.js" and 
> "../../../usr/share/nodejs/d3-collection/src/index.js" (will be ignored).
> created dist/d3.js in 1.9s
> 
> index.js → dist/d3.min.js...
> (!) Conflicting re-exports
> "index.js" re-exports "map" from both 
> "../../../usr/share/nodejs/d3-array/src/index.js" and 
> "../../../usr/share/nodejs/d3-collection/src/index.js" (will be ignored).
> created dist/d3.min.js in 4.2s
> -

I have pushed a commit to salsa that hopefully fixes this - can you please try 
with the same and see if that
helps you somewhat?

> So it's specifically "map" that is problematic, and I just happen to
> have stumbled upon it: d3 v5 depends on d3-array version 1, but the
> version of node-d3-array in unstable is 3.2.0+~cs5.0.6-2, and this is
> causing the conflict.
> 
> I don't know the best way to fix this.  node-d3-array version was
> upgraded from 1.2.4 to 3.x about two years ago, so d3 would have had
> this bug since then, but I'm the first one to stumble upon it :-/
>
> Perhaps we could package node-d3-array-1 (version 1.2.4) and have
> node-d3 build-depends on that?

I tried to embed it and realised it is creating an unholy mess. I got it 
working eventually
but it can open a can of worms sometime later. Maybe packaging the older version
would be the way to go if my fix above does not work.

I've added yadd to the thread for more qualified advice.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1064824: node-d3: fails to export map and other functions

[Nilesh Patra]

> This gives lots of differences still; stripping down to just the
> differences still has many, many differences: some new exports not in
> the original d3, and some lost exports; the list begins:
> $ diff -u /tmp/d3-npm.exports.trimmed /tmp/d3-debian.exports.trimmed
>
> +exports.Adder = Adder;
> -exports.bisect = bisectRight;
> +exports.bin = bin;
> +exports.bisect = bisect;
> +exports.bisectCenter = bisectCenter;
> +exports.blur2 = blur2;
> +exports.blur = blur;
> +exports.blurImage = blurImage;
> +exports.count = count;
> -exports.csvFormatRow = csvFormatRow;
> -exports.csvFormatValue = csvFormatValue;

$ cat /tmp/d3-debian.exports.trimmed | egrep --color 
'(bisectRight|csvFormatRow|csvFormatValue)'
exports.bisectRight = bisectRight;
exports.csvFormatRows = csvFormatRows;

Some of the diff entries are false positive -- it is just that entries are not 
identical across these
files and despite sorting them, you do not get the exact picture of the diff in 
exports.

However I did not find csvFormatValue and I dug a little bit into it. Seems 
this is sourced from node-d3-dsv
and exported with index.js: https://github.com/d3/d3/blob/v5.16.0/index.js

And checking on current unstable

| [/tmp/node-d3-dsv]$ git checkout debian/1.2.0+_1.2.3-1
| HEAD is now at 76229a9 releasing package node-d3-dsv version 1.2.0+~1.2.3-1
| [76229a9][/tmp/node-d3-dsv]$ grep -irn csvFormatValue
| types-d3-dsv/index.d.ts:195:// csvFormatValue(...) 

| types-d3-dsv/index.d.ts:202:export function csvFormatValue(value: string): 
string;
| src/csv.js:11:export var csvFormatValue = csv.formatValue;
| src/index.js:2:export {csvParse, csvParseRows, csvFormat, csvFormatBody, 
csvFormatRows, csvFormatRow, csvFormatValue} from "./csv.js";

So this should work, weird. I wanted to dig in, as per the build log: 
https://buildd.debian.org/status/fetch.php?pkg=node-d3=all=5.16.0%2B%7Ecs5.28.10-1=1693715544=0

| Selecting previously unselected package node-d3-dsv.
| Preparing to unpack .../317-node-d3-dsv_1.1.1-9_all.deb ...
| Unpacking node-d3-dsv (1.1.1-9) ...
| Selecting previously unselected packa

And

| [76229a9][/tmp/node-d3-dsv]$ git checkout debian/1.1.1-9   
| Previous HEAD position was 76229a9 releasing package node-d3-dsv version 
1.2.0+~1.2.3-1
| HEAD is now at 84fbfce releasing package node-d3-dsv version 1.1.1-9
| [84fbfce][/tmp/node-d3-dsv]$ grep -irn csvFormatValue | wc -l
| 0

Which is why. Seems the versions of dev dependencies have not been 
appropriately tightened by the upstream
so we are running into weird surprises like these. Re-compiling node-d3 again 
now should fixup this export however.

:-(

These minor deltas in exports are more or less due to
version differences in different d3 plugins.

> ...
> Background to this: I'm trying to package a new package which provides
> a web server to visualise some data.  The package includes a few
> precompiled JavaScript libraries obtained from npmjs.com, and the
> server works fine with them.  But following Debian policy, I need to
> replace those with the source packages.  And the server then doesn't
> work.
>
> The JavaScript libraries which the package uses are: d3 v5.16.0,
> d3-tip, apparently v0.9.1, along with jQuery and bootstrap4.  I have
> replaced all of these with the versions in the corresponding Debian
> packages (and I've just uploaded a new version of d3-tip, thinking
> that that was the cause of the bug).
>
> When visiting the served web page, the console log gives the error
> message:
>
> Uncaught (in promise) TypeError: t.map is not a function
>n http://localhost:8080/js/d3/d3-tip.min.js:1
>main http://localhost:8080/js/index.js:848
>async* http://localhost:8080/js/index.js:993
>
> (This has changed from the original bug report as the minimised new
> version of d3-tip has t.map instead of h.map.)
>
> d3-tip.js requires d3-collection, from which it calls a map function.
> I tried replacing d3-tip.min.js with the pre-packaged version rather
> than the (newly built) Debian version, but that did not help.  I
> reverted that change and instead replaced d3.v5.min.js (which is a
> copy of /usr/share/nodejs/d3/dist/d3.min.js) with the version provided
> by upstream, which is a verbatim copy of the npmjs.com d3.min.js, and
> the server then worked perfectly.  So this told me that it is the
> Debian compiled d3 which is not working correctly.

Julian, I am very confused by that wording - from what I could gauge, your
target package does not work with debian libs but it does work with npmjs, yes?

In that case linking your target package and listing the exact steps to
that error can help someone debug it in more detail as to what might be missing.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061806: lamassemble fails its autopkg tests with Python 3.12

[Nilesh Patra]

Hi Martin,

doko:
> Control: reopen -1
>
> please see the tests triggered by python3-defaults. Not pasting these 
> here in the bug report.
>
> https://autopkgtest.ubuntu.com/packages/l/lamassemble/noble/amd64

Would you be able to assist with this bug report?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061806

Here's the test script we use for lamassemble

https://salsa.debian.org/med-team/lamassemble/-/blob/master/debian/tests/run-unit-test?ref_type=heads

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#1037279: Angelfish built-in ad blocker not built due to missing Rust Build-Depends (Corrosion etc.)

[Nilesh Patra]

Quoting Nilesh Patra:
>> On Sat, 10 Jun 2023 05:09:08 +0200 Kevin Kofler  
>> wrote:
>> In addition to Corrosion, you will need cargo(though Corrosion should
>> already be requiring it), rust-adblock, rust-cxx-build, and rust-cxx.
> corossion, rust-adblock need packaging. Rest are in the archive already at 
> the moment. I doubt if we need
> corossion too, since this is mainly for comat with cmake based projects, and 
> we are usually not relying on
> submodule struct, and package things separately.

I have uploaded corrosion to NEW, it helps to build angelfish with adblock 
support
at least locally (with internet enabled fetching cargo deps).

Rest rust-cxx packages are in the archive already. rust-adblock is what we need.
I've filed an RFP bug#1063626 and pinged in rust-team IRC incase someone could 
pick
it up. I don't have the spoons to do so.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061832: kitty keyboard shortcut is not delivered to kitty window in focus

[Nilesh Patra]

Control: forwarded -1 https://github.com/kovidgoyal/kitty/issues/7116

On Tue, Jan 30, 2024 at 02:49:10AM +0530, Nilesh Patra wrote:
> I am unable to reproduce it in my machine and the mapping works just fine for 
> me.
> What is the desktop environment you use - what is the display server protocol 
> (wayland/x11)?
> Do you have any weird key mappings in your config?
> 
> Does it happen even with the upstream kitty binary? If so, can you please 
> report it in kitty's github
> tracker? Upstream is very responsive and can assist with this issue.

I have forwarded it upstream.

Best,
Nilesh


signature.asc
Description: PGP signature

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#1063273: seaborn: autopkgtest fail on i386 - probable rounding error

[Nilesh Patra]

On 9 February 2024 1:02:31 am IST, "Rebecca N. Palmer" 
 wrote:
>Control: tags -1 pending
>
>This appears to be fixed in Salsa (before I reported it) - is there any reason 
>not to upload this now?

When I initially uploaded it, debci said something like "regression on i386 - 
not a blocker" and I didn't see any signs of non-migration of seaborn. It was 
probably not updated properly.

I will upload seaborn by midnight or tomorrow evening.

Bug#1062404: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Nilesh Patra]

On Thu, Feb 01, 2024 at 01:55:21PM +0100, Sébastien Jodogne wrote:
> Even if I'm tagged as the maintainer of "orthanc-python", I don't know
> how autopkgtest/flaky works (I haven't implemented such tests by
> myself).

This is the script that runs for tests:


https://salsa.debian.org/med-team/orthanc-python/-/blob/master/debian/tests/run-unit-test?ref_type=heads

This is a basic script that should work and did work at least locally -- note 
that I only "sponsored"
an upload for this package and did not delve very deep into the working detaiks.

IDK why the logs are incomplete though.

> I consequently forward your message to the Debian Med mailing
> list, as I cannot help on this bug by myself.

If you prefer, we can drop this test altogether and test locally before each 
upload.


signature.asc
Description: PGP signature

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#1061857: Recommends: is too strong for dante-client

[Nilesh Patra]

On Thu, Feb 01, 2024 at 10:17:03AM +0100, Robin Jarry wrote:
> Nilesh Patra, Feb 01, 2024 at 10:07:
> > From what I gather, filters/html still uses socksify from dante package.
> > This looks OK as recommends - given that in 2024, people do get a bunch of 
> > HTML mails.
> > 
> > I want to close this bug if you agree.
> 
> We *could* drop it and change the default html filter to only use w3m
> without socksify.
> 
> Actually, aerc already ships an html-unsafe filter that does exactly that:
> 
> https://git.sr.ht/~rjarry/aerc/tree/master/item/filters/html-unsafe
> 
> The name may be frightening, I guess we could remove the hard dependency to
> socksify. People with high concerns for privacy can always tweak it to their
> needs.
> 
> Thoughts?

This probably should only be done if/when the default html filter is update to
not use socksify. I don't want end users to run into surprises.


signature.asc
Description: PGP signature

Bug#1061857: Recommends: is too strong for dante-client

[Nilesh Patra]

> [ I wanted to git-blame the control file, and/or submit a patch, but
>  Salsa is down right now and I couldn't find a mirror ]

This is the relevant commit:

commit 4077340f13b46f2fd9dcb17d3f50b4a59292530c (tag: debian/0.3.0-1)
Author: Ben Fiedler 
Date:   Sat Apr 25 17:57:31 2020 +0200

Recommend dante-client and w3m

These packages are used for viewing html mails using the default html
filter.

From what I gather, filters/html still uses socksify from dante package.
This looks OK as recommends - given that in 2024, people do get a bunch of HTML 
mails.

I want to close this bug if you agree.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes

[Nilesh Patra]

On Tue, Jan 30, 2024 at 08:05:35AM +, Rebecca N. Palmer wrote:
> In particular, I'd like the seaborn fix uploaded before pandas, so I can set
> Breaks for it.  (The pandas documentation build-depends on seaborn.)

https://tracker.debian.org/news/1498923/accepted-seaborn-0132-1-source-into-unstable/

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061832: kitty keyboard shortcut is not delivered to kitty window in focus

[Nilesh Patra]

Hi Marc,

On Mon, Jan 29, 2024 at 09:15:00PM +0100, Marc Kleine-Budde wrote:
> Package: kitty
> Version: 0.32.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>  updating from 0.21.2-2 to basically anything newer
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  I start several kitty windows with "kitty -1".
>  kitty.conf contains "map kitty_mod+t new_tab".

I am unable to reproduce it in my machine and the mapping works just fine for 
me.
What is the desktop environment you use - what is the display server protocol 
(wayland/x11)?
Do you have any weird key mappings in your config?

Does it happen even with the upstream kitty binary? If so, can you please 
report it in kitty's github
tracker? Upstream is very responsive and can assist with this issue.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression

[Nilesh Patra]

+Maytha who prepared the upload.

On Sun, Jan 28, 2024 at 05:05:55PM +, Julian Gilbey wrote:
> Hi Nilesh,
> 
> You did the last upload of this package - do you have any idea about
> this bug?

I've been trying to track it down for the past hour but I don't have a fix that 
I am confident about.
I initially thought it may have been due to some sort of overflow due to 
bitshift so I applied this patch

--- a/fuse/print.go
+++ b/fuse/print.go
@@ -119,7 +119,8 @@
 func (names *flagNames) set(flag int64, name string) {
entry := flagNameEntry{bits: flag, name: name}
for i := 0; i < 64; i++ {
-   if flag&(1< Best wishes,
> 
>Julian
> 
> - Forwarded message from Paul Gevers  -
> 
> Date: Sun, 28 Jan 2024 08:50:51 +0100
> From: Paul Gevers 
> Subject: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to
>   testing for too long: i386 autopkgtest regression
> To: sub...@bugs.debian.org
> 
> Source: golang-github-hanwen-go-fuse
> Version: 2.1.0+git20220822.58a7e14-1
> Severity: serious
> Control: close -1 2.4.2-1
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:golang-github-hanwen-go-fuse has been trying to migrate
> for 31 days [2]. Hence, I am filing this bug. The version in unstable fails
> its own autopkgtest on i386.
> 
> If a package is out of sync between unstable and testing for a longer period,
> this usually means that bugs in the package in testing cannot be fixed via
> unstable. Additionally, blocked packages can have impact on other packages,
> which makes preparing for the release more difficult. Finally, it often
> exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing. I
> have also tagged this bug to only affect sid and trixie, so it doesn't affect
> (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=golang-github-hanwen-go-fuse
> 
> 
> 
> 
> 
> - End forwarded message -
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1034327: nmodl: reproducible-builds: Embedded build path in /usr/bin/nmodl

[Nilesh Patra]

On Sat, Jan 27, 2024 at 09:09:12PM +0530, Nilesh Patra wrote:
> > The build path is embedded in /usr/bin/nmodl:
> >
> >  
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nmodl.html
> >
> >  /build/1st/nmodl-0.5/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib
> >  vs.
> >  /build/2/nmodl-0.5/2nd/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib
> 
> Thanks for the patch, I have applied it. can I ask you to forward it upstream 
> as well?

Seems this patch causes the package to FTBFS so I dropped it. However, I see 
salsa CI
as green even w/o this patch so I'm keeping this bug as closed.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1034327: nmodl: reproducible-builds: Embedded build path in /usr/bin/nmodl

[Nilesh Patra]

> The build path is embedded in /usr/bin/nmodl:
>
>  
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nmodl.html
>
>  /build/1st/nmodl-0.5/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib
>  vs.
>  /build/2/nmodl-0.5/2nd/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib

Thanks for the patch, I have applied it. can I ask you to forward it upstream 
as well?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061576: stringtie: "possible missing binaries"

[Nilesh Patra]

Hi,

> Package: stringtie
>
> I wish to access prepDE.py and/or prepDE.py3 binaries

Are these actually useful for end-users (which also includes you)?

If so, I will make a new upload to include these scripts as well.

Let me know.

Best,
Nilesh


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#1056504: python-sparse's autopkg tests fail with Python 3.12

[Nilesh Patra]

On Sat, Jan 13, 2024 at 09:03:07AM +0100, Andreas Tille wrote:
> This is surely due to the removal of versioneer in upstream commit
> 6fca42bc1cd0acea2153b074658b834231a4d00f  - but I can't imaginge upstream
> simply left the according responsible line
> 
> sparse/__init__.py:from ._version import __version__, __version_tuple__  # 
> noqa: F401
> 
> and did not noticed that tests are failing.  Am I missing something?

Fixed in Git, please check.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1057067: RFS: rclone (update) + dep

[Nilesh Patra]

On Wed, Dec 27, 2023 at 12:14:30PM +0800, Maytham Alsudany wrote:
> Hi Nilesh,
> 
> On Tue, 2023-12-26 at 21:38 +0530, Nilesh Patra wrote:
> > On 12/26/2023 7:52 AM IST Maytham Alsudany  wrote:
> > > Hi Go team,
> > > 
> > > I require a sponsor to review and upload the following packages for me.
> > > 
> > > Updated:
> > > - rclone (update to 1.65.0, team upload)
> > > Significant changes, please see changelog / commit history
> > > - golang-github-hanwen-go-fuse (update to 2.4.2, team upload)
> > 
> > Hi, did you run ratt to check if something breaks?
> 
> Yes, all rdeps pass for go-fuse.

I have uploaded this.

> > For rclone you might want to ask Tobias/Matthew for a review.
> 
> CC'd the new upstream version bug.

You might want to ask/CC the uploaders as well, since the new upstream bug goes
to the go team tracker email address.

PS: I will *not* be able to review anything for the next few days so I shall
take a look at other RFS later. Happy new year!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1057067: RFS: rclone (update) + dep

[Nilesh Patra]

On 12/26/2023 7:52 AM IST Maytham Alsudany  wrote:
> Hi Go team,
> 
> I require a sponsor to review and upload the following packages for me.
> 
> Updated:
> - rclone (update to 1.65.0, team upload)
> Significant changes, please see changelog / commit history
> - golang-github-hanwen-go-fuse (update to 2.4.2, team upload)

Hi, did you run ratt to check if something breaks?

For rclone you might want to ask Tobias/Matthew for a review.

Best,
Nilesh

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#1059382: kitty: Text rendering change

[Nilesh Patra]

Hi Weasley,

On 24 December 2023 8:58:14 am IST, Wesley Schwengle  
wrote:
>Package: kitty
>Version: 0.31.0-3
>Severity: normal
>X-Debbugs-Cc: wes...@schwengle.net
>
>Dear Maintainer,
>
>On Debian stable version 0.26.5 of kitty is running, on testing/unstable this
>is 0.31.0. In 0.28.0 a change in text rendering is made by upstream, this is
>mentioned in the changelog.
>
>
>Text rendering change: Use sRGB correct linear gamma blending for nicer font
>rendering and better color accuracy with transparent windows. See the option
>text_composition_strategy for details. The obsolete macos_thicken_font will
>make the font too thick and needs to be removed manually if it is configured.
>(#5969)
>
>I didn't spot it and went in full bisect mode to figure out which commit caused
>it. I found it and could relate it to the Changelog entry.

Thanks for reporting it and taking the time to bisect it as well!

>The issue is that on a dark background with light text everything is made bold,
>whereas previously this was not bold. I think it is wise to inform users that
>`text_composition_strategy legacy` restores the old defaults (similar to the
>version in stable) and/or refer to the manual page:
>
>https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.text_composition_strategy
>
>If kitty can read a system-wide config it might be set there.

It can, but honestly I don't want to diverge from upstream here. Everyone may 
not like the said change and enforcing a system wide config for a composition 
change isn't something that I'm willing to do.

If you could, please consider opening up an upstream issue to see if we can 
reach a common ground. If not, I'll just add a d/NEWS entry informing 
users/sysadmin about this change.

Thanks,
Nilesh

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#1057847: tombo: FTBFS with Python 3.12

[Nilesh Patra]

On Sat, 09 Dec 2023 16:18:35 +0100 Bas Couwenberg  wrote:
> It builds successfully when using cython 3.0 from experimental.

Hence there's nothing we could do except for waiting for cython upload to 
unstable.

Best,
Nilesh

Bug#1055692: macs ftbfs with Python 3.12

[Nilesh Patra]

Control: clone -1 -2
Control: reassign -2 cython
Control: found -2 0.29.36-3
Control: severity -2 serious

On Fri, 10 Nov 2023 09:03:41 +0100 Matthias Klose  wrote:
> Package: src:macs
> Version:
> Severity: important
> Tags: sid trixie
> User: debian-pyt...@lists.debian.org
> Usertags: python3.12
> 
> macs ftbfs with Python 3.12 (note that also cython 3.0.5 was used)
> 
> [...]
> dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:310: python3.12 setup.py config
> 

It currently FTBFS with:

MACS3/Signal/HMMR_EM.c:1474:32: error: ‘_PyCFrame’ has no member named 
‘use_tracing’
 1474 |  (unlikely((tstate)->cframe->use_tracing) &&\
  |^~
MACS3/Signal/HMMR_EM.c:978:43: note: in definition of macro ‘unlikely’
  978 |   #define unlikely(x) __builtin_expect(!!(x), 0)
  |   ^

We can revisit the bug once cython3 is updated to >= 3.0.5 and the build-deps 
of macs (particularly cykhash) are
rebuilt. Also cloning and reassigning to cython so this could be upgraded.
Best,
Nilesh

Bug#1054602: mosdepth: Needs "libhts.so" as a dependency, avaialbe in package "libhts-dev"

[Nilesh Patra]

On Fri, 27 Oct 2023 07:31:31 +0200 Andreas Tille  wrote:> 
Am Thu, Oct 26, 2023 at 12:24:20PM -0400 schrieb Frank Bearoff:

> * What led up to the situation?
> sudo apt install "mosdepth"

OK, you installed the package - but what did you after installing it?
Which command did you called that failed and is exposing the problem?

I checked the linked libraries:

$ ldd /usr/bin/mosdepth 
linux-vdso.so.1 (0x7fffa19fc000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb43a39d000)
/lib64/ld-linux-x86-64.so.2 (0x7fb43a657000)



It should be as simple as to reproduce:

$ sudo apt install mosdepth
$ mosdepth -h
could not load: libhts.so
(compile with -d:nimDebugDlOpen for more information)



It does not sound very convincing that the development package is
needed.  Most probably your system will be solved by installing libhts3.
But first I would like to know what the problem really is.


Not really. As per the readme of mosdepth:

| The binary from releases is static, with no dependencies. If you build it 
yourself,
| `mosdepth` requires htslib version 1.4 or later. If you get an error
| about "`libhts.so` not found", set `LD_LIBRARY_PATH` to the directory that
| contains `libhts.so`. e.g.
|
| `LD_LIBRARY_PATH=~/src/htslib/ mosdepth -h`
|
| If you get the error `could not import: hts_check_EOF` you may need to
| install a more recent version of htslib.

Since we are not building a static lib of htslib, we need a .so file for 
mosdepth
to consume.


> * What was the outcome of this action?
> mosdepth works

Please define `works`.  As in the given test CI links it works as
well.


That's because it has a test dependency on libhts-dev


> It appears "mosdepth has the undecalred dependency of "libhts-dev"

Dependencies from libraries are usually detected automatically which
works in general with extremely rare exceptions.


Note that this is a package written in nim which is a (relatively) new language 
and
has almost zero support from other (debian) tools, so much so that it does not 
have
its own debhelper tool.


Its very uncommon that
a non-development package needs a *-dev package.


I think in this case it really needs a '.so' in place. So I am adding this in 
depends
and uploading a fix. LMK if you disagree.

@Frank, thanks for reporting!

Best,
Nilesh

Bug#1029202: Could some SnpEff user from the community please ping authors

[Nilesh Patra]

On Tue, Nov 28, 2023 at 05:54:30PM +0100, Andreas Tille wrote:
> I wonder whether some people from the community might be able to join
> our attempt to get this issue fixed and raise their voice inside the
> Github issue (or use other channels) to get this finally fixed.  I guess
> the problem does not only occure in snippy test suite but also in other
> pipelines so the community might be affected by this issue.
> 
> 
> [1] https://github.com/pcingola/SnpEff/issues/455

Sometimes just tagging upstream author does wonders :)

They have replied and the (upstream) bug has been closed.
BTW, are you able to still reproduce (without any fixes for snpeff/snippy) 
#1031465?

For me, it is working fine in an unstable chroot (including autopkgtests)
and maybe could be closed.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved

[Nilesh Patra]

On Mon, Nov 20, 2023 at 04:41:05PM +0530, Pirate Praveen wrote:
> > This maybe a setup/configuration issue for your system. I did find a
> > similar issue on the systemd repository itself[1] and the fix was to add
> > in a "DNS=" entry in resolved.conf. Can you try this and report back?
> 
> I already have DNS= 103.87.68.194 (opennic.org dns resolver) set to and
> FallbackDNS=9.9.9.9
> 
> I also had DNSOverTLS=yes. After disabling this host command works.

I still can't reproduce after trying this setting. I set this as a global 
setting:

$ resolvctl status
Global
  Protocols: +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
   resolv.conf mode: uplink
 Current DNS Server: 9.9.9.9
 DNS Servers 9.9.9.9
Fallback DNS Servers 1.1.1.1
  DNS Domain ~.

And I am able to use riseup-vpn without any issues. Seems this is something 
else on
your system. Can you share all the logs you see right from the point you run 
riseup-vpn
from terminal?

I need something that I could reproduce to be able to further check.


signature.asc
Description: PGP signature

Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved

[Nilesh Patra]

Control: severity -1 normal
Control: tags -1 moreinfo

On Mon, 20 Nov 2023 12:36:51 +0530 Pirate Praveen  wrote:
> It misses a dependency on openvpn-systemd-resolved and on boomworm it 
> was working after installing it.

I do not have this installed however riseup-vpn works for me without any
issues. Others who have tested this package on bookworm in the past also
did not have any such issues.

I tried with systemd-resolved installed without openvpn-systemd-resolved
install - no problems observed.

> But on mobian trixie, which has 
> systemd-resolved installed by default (through mobian-base), dns 
> resolution fails when riseup vpn is connected.

I do not have a device to try out mobian. I tried it on debian
trixie/testing with openvpn-system-resolved and I do not see any such
issue.

> ;; communications error to 127.0.0.53#53: timed out
> ;; communications error to 127.0.0.53#53: timed out
> ;; no servers could be reached

OTOH, this log has very superficial info and is not helpful into
debugging if there's even anything wrong with riseup-vpn.

This maybe a setup/configuration issue for your system. I did find a
similar issue on the systemd repository itself[1] and the fix was to add
in a "DNS=" entry in resolved.conf. Can you try this and report back?

Could you also check this on a different network connection?

[1]: https://github.com/systemd/systemd/issues/25397

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)

[Nilesh Patra]

On Fri, Nov 17, 2023 at 06:18:04PM +0800, Maytham Alsudany wrote:
> golang-github-go-logfmt-logfmt doesn't have this Handler type that's being 
> used,
> and humanlog already uses go-logfmt as much as it can
> 
> I've made an issue upstream at [3] regarding this and I've patched out the
> Handler type completely from humanlog for now.
> 
> Would you like me to close this RFS bug and the ITP?

If this is needed for some actual functionality in humanlog, I will upload 
kr-logfmt
which would otherwise block your work.

From your mail, it is not clear to me whether or not it is needed.
Please let me know.

> [1]: https://bugs.debian.org/1055740
> [2]:
> https://salsa.debian.org/go-team/packages/golang-github-humanlogio-humanlog/
> [3]: https://github.com/humanlogio/humanlog/issues/71


Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)

[Nilesh Patra]

On Wed, Nov 15, 2023 at 04:26:47PM +0800, Maytham Alsudany wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: debian...@lists.debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "golang-github-kr-logfmt":
> 
>  * Package name : golang-github-kr-logfmt
>Version  : 0.0~git20210122.19f9bcb-1
>Upstream contact : https://github.com/kr/logfmt/issues
>  * URL  : https://github.com/kr/logfmt
>  * License  : Expat
>  * Vcs  : 
> https://salsa.debian.org/go-team/packages/golang-github-kr-logfmt
>Section  : golang

This looks like _really_ old code, and there's
golang-github-go-logfmt-logfmt in debian already.

Can the code in the target package be patched to use go-logfmt or is it
using specific features from kr-logfmt?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055975: RFS: golang-connectrpc-connect/1.12.0-1 [ITP] -- Go implementation of Connect

[Nilesh Patra]

On Wed, Nov 15, 2023 at 03:57:11PM +0800, Maytham Alsudany wrote:
> I am looking for a sponsor for my package "golang-connectrpc-connect":
> 
>  * Package name : golang-connectrpc-connect
>Version  : 1.12.0-1
>Upstream contact : https://github.com/connectrpc/connect-go/issues
>  * URL  : https://github.com/connectrpc/connect-go
>  * License  : Apache-2.0
>  * Vcs  : 
> https://salsa.debian.org/go-team/packages/golang-connectrpc-connect
>Section  : golang

Uploaded to NEW with minor nitpicks. BTW, there is no real need to create
a RFS bug if you want it to be under go team. Just sending a mail should
suffice.

PS: Are you subscribed to the debian-go team mailing list? Can I stop CC'ing 
you?

Best,
Nilesh


signature.asc
Description: PGP signature

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-dh-golang
> > > > > [3]: https://salsa.debian.org/Mayth

Bug#1042406: dh-r: throws "Use of uninitialized value $dep_line in substitution" warnings with some packages

[Nilesh Patra]

On Thu, 27 Jul 2023 22:07:23 +0200 Andreas Tille  wrote:
> Am Thu, Jul 27, 2023 at 11:51:42PM +0530 schrieb Nilesh Patra:
> > 
> > On checking further, it seems to be stemming from the recommends line in
> > dh-r code[1]. This is because recommendsinput variable is being directly
> > set from desc->{Recommends}, and a check of whether this field is empty
> > is *after* the said initialization[3]. This can lead to `recommendsinput`
> > being set as `undef` and hence the unintialized errors from debhelper.
> 
> That's a pretty sensible explanation for the problem.
>  
> > The reason that we don't see such problems in for instance
> > r-bioc-bsgenome is because it has some values in the testdepends and
> > recommendsinput ends up having some value[4].
> > 
> > I have attached a patch to fix this, please check.
> 
> While reading the patch it definitely fixes the uninitialized value.
> However, it does not fulfill the intended behaviour to add the
> Test-Depends as Recommends.  I'm considering parsing DESCRIPTION
> directly to do so.
> 
> > ** Please test properly before you merge and upload, do NOT upload
> > blindly **
> 
> Thanks a lot for the warning.  I'll leave the bug open as a reminder
> and will sleep over it for a couple of nights to decide what might be
> the best solution for the problem.

I guess it has been a little bit longer than a couple of nights since
the bug report :)

We digressed discussing adding test depends as recommends - which was
not the purpose of this bug or even patch. It was rather to fix a
warning that dh-r spews sometimes and AFAICS, there is no regression.

have you thought about merging or rejecting the patch yet?

> > PS: Please mention my contribution in d/ch if you take this patch.
> 
> Sure. ;-)


Best,
Nilesh


signature.asc
Description: PGP signature

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 latest lintian report from the (newly discovered) 

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#1037440: kitty: Integrating golang parts of the package

[Nilesh Patra]

On Sun, Nov 05, 2023 at 10:09:44AM -0500, James McCoy wrote:
> The former is fine with me.  I took a quick look at what Fedora is
> doing, and it looks like they just patch setup.py to return from
> build_static_kittens() just before the “go build -v” line.
> 
> Adding a patch for that and then adapting the rest of the Debian side of
> the build to do it seems reasonable.

Right. So I have an update for you. I have attached a patch on top of
MR!3 [1] with this mail which gets the go parts (static kitten binary) building
for me \o/.
I wanted to commit directly but admittedly the non-gbp flow is
confusing for me so I left figuring this out for later.

I tried testing it locally and so far it does work as I expect it to.

I did the following changes:
* GO111MODULE should be turned off for debian specific builds otherwise
  it tries to fetch packages from the internet which is forbiden in
  build.
* Add dh_auto_configure for go counterpart as it'd initialize a _build
  directory with symlink to all packages. This saves us from some of the
  manual work which is done for example in[2].
* Added a corresponding clean directive too so as to cleanup _build
* I realised using dh_auto_build with go profiles is not something that
  works smoothly as it expects go files in 'kitty/' and it has none.
  There are a couple of other caveats too, so using 'go build '
  works better.
* Copied some generated header files in python counter part's build to
  _build directory
* Since some files did not get copied by go's dh_auto_configure they
  have been specified in DH_GOLANG_INSTALL_EXTRA
* Added a patch to ignore checking go version from go.mod as go list -m
  does not work with GO111MODULE set to off. This needs to be adjusted
  in d/control anyway
* Added kitten binary in d/kitten.install
* Add a XS-Go-Import-Path field in d/control in accordance with the
  package name in go.mod
* Update build deps and add versioned B-D on exp-dev

-> Note that exp-dev needs to be updated in debian. Since this is a key
package I have pinged the maintainer (on IRC) to do it. For this build,
I locally updated this and a couple other packages in the chain. You can
use the .debs for these from here[3]

-> I skipped the tests in d/rules as python specific stuff fails. I
leave the onus of fixing this on you :)

I hope this helps!

[1]: https://salsa.debian.org/debian/kitty/-/merge_requests/3
[2]: 
https://sources.debian.org/src/ncbi-entrez-direct/19.2.20230331+dfsg-3/debian/rules/
[3]: https://people.debian.org/~nilesh/kitty/

Best,
Nilesh
commit 281201ccddfee95a606d82e1860fa3ea73d355fd
Author: Nilesh Patra 
Date:   Mon Nov 6 03:05:17 2023 +0530

Changes to get kitten building

diff --git a/debian/control b/debian/control
index 3258bcc61..66ceda63c 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Maintainer: James McCoy 
 Section: x11
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
+XS-Go-Import-Path: kitty
 Homepage: https://sw.kovidgoyal.net/kitty/
 Vcs-Git: https://salsa.debian.org/debian/kitty.git
 Vcs-Browser: https://salsa.debian.org/debian/kitty
@@ -17,7 +18,7 @@ Build-Depends:
  furo ,
  golang-any,
  golang-github-altree-bigfloat-dev,
- golang-github-alecthomas-chroma-dev,
+ golang-github-alecthomas-chroma-v2-dev,
  golang-github-bmatcuk-doublestar-dev,
  golang-github-disintegration-imaging-dev,
  golang-github-dlclark-regexp2-dev,
@@ -26,7 +27,7 @@ Build-Depends:
  golang-github-seancfoley-ipaddress-go-dev,
  golang-github-shirou-gopsutil-dev,
  golang-github-zeebo-xxh3-dev,
- golang-golang-x-exp-dev,
+ golang-golang-x-exp-dev (>= 0.0~git20230801),
  golang-golang-x-image-dev,
  golang-golang-x-sys-dev,
  golang-howett-plist-dev,
diff --git a/debian/kitty.install b/debian/kitty.install
index fe49de93f..63b03ef63 100644
--- a/debian/kitty.install
+++ b/debian/kitty.install
@@ -1,4 +1,5 @@
 debian/tmp/usr/bin/kitty
+debian/tmp/usr/bin/kitten
 debian/tmp/usr/lib/
 debian/tmp/usr/share/applications/kitty.desktop
 debian/tmp/usr/share/icons/
diff --git a/debian/patches/fix-version.patch b/debian/patches/fix-version.patch
new file mode 100644
index 0..063c9d7d6
--- /dev/null
+++ b/debian/patches/fix-version.patch
@@ -0,0 +1,25 @@
+Description: "go list -m" does not work with GO111MODULE set to off. Disable version checking for now.
+ Also build the static kittens via debian buildsystem instead of the upstream one.
+Author: Nilesh Patra 
+Forwarded: not-needed
+Last-Update: 2023-11-06
+--- a/setup.py
 b/setup.py
+@@ -964,12 +964,13 @@
+ go = shutil.which('go')
+ if not go:
+ raise SystemExit('The go tool was not found on this system. Install Go')
+-required_go_version = subprocess.check_output([go] + 'list -f {{.GoVersion}} -m'.split()).decode().strip()
+-current_go_version = subprocess.check_output([go, 'version']).decode().strip().split()[2][2:]
+-if parse_go_version(required_go_version) > parse_go_version(current_go_version):
+-

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#1042698: python-vispy: FTBFS with Sphinx 7.1, docutils 0.20: AttributeError: 'container' object has no attribute 'html5tagname'

[Nilesh Patra]

Hi Lucas,

On Sun, 30 Jul 2023 20:33:09 +0200 Lucas Nussbaum  wrote:
> Source: python-vispy
> Version: 0.6.6-3
> Severity: important
> Tags: ftbfs

This seems to be an older version of vispy and the latest one in
bookworm no longer FTBFS with newer sphinx for me locally.

Could you please trigger a job on the latest vispy version as well so we
could close this?

Thanks!


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#1052347: src:canu: fails to migrate to testing for too long: unresolved RC issue

[Nilesh Patra]

On Wed, 1 Nov 2023 19:23:13 +0100 Paul Gevers  wrote:
> Hi Andreas,
> 
> On 01-11-2023 07:34, Andreas Tille wrote:
> >... is it possible that the CI is restricting memory so when it tries
> >to allocate some it fails?
> 
> Because of lack of automatic reporting, I created this wiki some time ago:
> https://wiki.debian.org/ContinuousIntegration/WorkerSpecs
> 
> The memory for the arm64 workers isn't huge (8GB), but all i386 and some 
> of the amd64 workers have the same.

On the same threads, Michael said that he is not able to reproduce the error on 
arm64 porter box however it fails in debci.

The upstream needs the *.out files of the failing tests, as they said at [1]. 
Since it does not work on porter box, and chokes on the CI infra, could you 
please provide these files?

[1]: https://github.com/marbl/canu/issues/2271#issuecomment-1772870568

Thanks,
Nilesh

Bug#1055293: dub: Please upgrade to a new version

[Nilesh Patra]

Package: dub
Version: 1.27.0-4
Severity: important
X-Debbugs-Cc: m...@debian.org

Dear Maintainer,

dub seems to be at a really old version and it is just "limping" to stay
in testing at the moment and the version there was released 3 years
back, this is behind a bunch of new releases.

I noticed there is a new version committed to salsa but it does not
build and this seems unfixed upstream as well. I however did find a
(unmerged) PR that fixes it:

https://github.com/dlang/dub/pull/2623

IMHO dub should be updated to latest version once those rough edges are
sorted out.

Thanks,
Nilesh

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1055286: r-cran-spatstat.core: Fails autopkgtests on all archs

[Nilesh Patra]

Source: r-cran-spatstat.core
Version: 2.4-4-2
Severity: serious
Tags: trixie sid

Dear Maintainer,

Spatstat.core fails its autopkgtests with:

This is due to an API change in spatstat.random to which this package
did not adapt to.


https://github.com/spatstat/spatstat.random/commit/5e90d382ee6a4bbb6266b5b77d832f3dcc129b3b

It has also been removed from CRAN and archive since December 22.

https://cran.r-project.org/web/packages/spatstat.core/index.html

It may make sense to remove it altogether but it should be removed from
testing for sure.

Thanks,
Nilesh

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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#1055107: crowdsec fails its autopkgtests on armel

[Nilesh Patra]

On Tue, Oct 31, 2023 at 05:32:53PM +0100, Cyril Brulebois wrote:
> Nilesh Patra  (2023-10-31):
> > On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra  wrote:
> > Full log at: 
> > https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz
> > 
> > > This is currently blocking golang-github-gin-gonic-gin to testing which
> > > fixes a bunch of RC bugs (of same kind).
> 
> I think we've had this issue showing up in a few cases (on other archs
> though), but I wasn't able to replicate it, possibly timing issues or
> something similar.

Since this means it is a flaky test and a recurring problem, would it
make sense to skip those tests to save some cycles for debci?

> I'd suggest a retry if that wasn't attempted already.

I had triggered it - we will see if it fixes itself.


Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055107: crowdsec fails its autopkgtests on armel

[Nilesh Patra]

On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra  wrote:
> Source: crowdsec
> Version: 1.4.6-6
> Severity: serious
> X-Debbugs-Cc: k...@debian.org
> 
> Dear Maintainer,
> 
> crowdsec fails its autopkgtests on unstable with:
> 
> | 316s === RUN   TestOneShot
> | 316s journalctl_test.go:172: Expected log output 'journalctl: invalid 
> option' but got nothing !
> | 316s --- FAIL: TestOneShot (0.08s)
> | 316s === RUN   TestStreaming
> | 316s journalctl_test.go:181: unreliable test: 
> https://github.com/crowdsecurity/crowdsec/issues/2352
> | 316s --- SKIP: TestStreaming (0.00s)
> | 316s FAIL
> | 316s FAIL   
> github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/journalctl0.225s
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers 
> [no test files]
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers/v1  
> [no test files]
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/apiserver/middlewares/v1  
> [no test files]
> | 319s ?  github.com/crowdsecurity/crowdsec/pkg/cstest[no test files]
> 

Full log at: 
https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz

> This is currently blocking golang-github-gin-gonic-gin to testing which
> fixes a bunch of RC bugs (of same kind).

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055107: crowdsec fails its autopkgtests on armel

[Nilesh Patra]

Source: crowdsec
Version: 1.4.6-6
Severity: serious
X-Debbugs-Cc: k...@debian.org

Dear Maintainer,

crowdsec fails its autopkgtests on unstable with:

| 316s === RUN   TestOneShot
| 316s journalctl_test.go:172: Expected log output 'journalctl: invalid 
option' but got nothing !
| 316s --- FAIL: TestOneShot (0.08s)
| 316s === RUN   TestStreaming
| 316s journalctl_test.go:181: unreliable test: 
https://github.com/crowdsecurity/crowdsec/issues/2352
| 316s --- SKIP: TestStreaming (0.00s)
| 316s FAIL
| 316s FAIL 
github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/journalctl0.225s
| 319s ?github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers 
[no test files]
| 319s ?github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers/v1  
[no test files]
| 319s ?github.com/crowdsecurity/crowdsec/pkg/apiserver/middlewares/v1  
[no test files]
| 319s ?github.com/crowdsecurity/crowdsec/pkg/cstest[no test files]

This is currently blocking golang-github-gin-gonic-gin to testing which
fixes a bunch of RC bugs (of same kind).

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#969177: debmake: cannot create deb for nodejs modeule

[Nilesh Patra]

Control: tags -1 patch

On Thu, 26 Oct 2023 23:25:00 +0530 Akshay S Dinesh  wrote:
> On Thu, 14 Jul 2022 16:37:52 +0200 Pirate Praveen 
>  wrote:
> > Control: reopen -1
> > Control: notfixed 4.4.0-1
> > 
> > On Thu, 14 Jul 2022 10:54:14 +0200 Pirate Praveen
> >  wrote:
> > > Control: fixed -1 4.4.0-1
> > > 
> > > Looks like it is fixed in current version, closing this bug. Thanks!
> > 
> > Seems like I was mistaken, tried on a fresh clean chroot and it still
> > fails.
> > 
> > 
> 
> 
> There's this commit referencing 4.4.0-1 on June 25, 2021 
> https://salsa.debian.org/debian/debmake/-/commit/c59f0dbc112c5aaa737e0afdacbcc193e5e17dea
> 
> And this commit which fixes the bug on June 26, 2021 
> https://salsa.debian.org/debian/debmake/-/commit/7f6c310aff8bf13eb64b98aff14e5e0b2bd58301
> 
> And this commit on May 6, 2022 which talks about 4.4.0
> https://salsa.debian.org/debian/debmake/-/commit/07b1e07a9d9d327778d535287fdc70ac05dbe9e4
> 
> I'm unsure what's what.

It sure has been committed, and it is also present in the source package
in the archive too. Seems to me that the uploader uploaded this on May
6, 2022 but did not edit the date as can be confirmed from the
upload entry as well.


https://tracker.debian.org/news/1323132/accepted-debmake-440-1-source-into-unstable/

> https://packages.debian.org/sid/all/debmake/filelist is missing 
> /usr/share/debmake/extra0desc_long/nodejs

Right that's because the changes in the commit are incomplete to fix this bug,
since the nodejs extradesc file is never installed because it has its entry
missing from setup.cfg.

I've attached a (one-line) patch at the end of the mail to fix this up properly.

> In any case, a workaround is to do
> 
> echo " This package contains the nodejs program." | sudo tee 
> /usr/share/debmake/extra0desc_long/nodejs


I was surprised to know that debmake tries to take the "type" field of
the package from the directory name itself. So another workaround (this
one is admittedly stupid) is:

| $ mv node-pretty-ms-8.0.0 pretty-ms-8.0.0
| $ cd pretty-ms-8.0.0
| $ debmake
| $ cd ..
| $ mv pretty-ms-8.0.0 node-pretty-ms-8.0.0

Though after this it'd take some effort to edit source package name.

Best,
Nilesh


diff --git a/setup.cfg b/setup.cfg
index 57235a5..b19b18c 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -54,6 +54,7 @@ console_scripts =
src/extra0desc_long/dev
src/extra0desc_long/doc
src/extra0desc_long/lib
+   src/extra0desc_long/nodejs
src/extra0desc_long/perl
src/extra0desc_long/python
src/extra0desc_long/python3


signature.asc
Description: PGP signature

Bug#1032107: Don't release with bookworm

[Nilesh Patra]

Hi Shengjing,

On Tue, 28 Feb 2023 13:43:13 +0800 Shengjing Zhu  wrote:
> Source: golang-github-jesseduffield-go-getter
> Version: 0.0~git20180822.906e156-5
> Severity: serious
> X-Debbugs-Cc: z...@debian.org
> 
> 
> Fork of golang-github-hashicorp-go-getter.
> No new development in https://github.com/jesseduffield/go-getter since 2018
> No reverse-depends.

You had filed a bunch of such bugs before bookworm release. Do you think
it is fine to remove them from the archive?

If so these BRs could be convered to ROM.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1037409: golang-golang-x-exp ftbfs with gccgo-go (both gccgo-12 and gccgo-13)

[Nilesh Patra]

Control: severity -1 important

On Mon, 12 Jun 2023 18:23:39 +0530 Pirate Praveen  wrote:
> Package: src:golang-golang-x-exp
> Version: 0.0~git20221028.83b7d23-2
> Severity: serious
> 
> Building with golang-any changed to gccgo-go to force gccgo on amd64, 
> build fails with error. Full build log attached. Either this should be 
> fixed or dependency should be updated to golang-go instead of golang-any.
> 
> golang.org/x/exp/maps
> # golang.org/x/exp/maps
> src/golang.org/x/exp/maps/maps.go:10:10: error: expected ‘(’
> 10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
>|  ^

Seems like gccgo is not able to recognize tilde -- could that be an
issue at the toolchain level itself?

I'm also reducing the severity to important since this does build in
principle. Perhaps the B-D should be changed to golang-go explicitly.

Best,
Nilesh


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