Bug#1102498: ITP: llm.nvim -- LLM powered development for Neovim

[M. Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: llm.nvim
* URL : https://github.com/huggingface/llm.nvim
* License : Apache-2.0
  Programming Lang: Lua
  Description : LLM powered development for Neovim

Copilot.vim alternative that allows you to use an alternative
backend server like a self-hosted LLM inference server such
as vLLM, etc.

Thank you for using reportbug

Bug#1102566: ITP: nuntium -- Bridges push notifications from ofono to telepathy-ofono

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: nuntium
  Version : 2.2~git
  Upstream Contact: UBports developers 
* URL : https://gitlab.com/ubports/development/core/nuntium
* License : GPL-3
  Programming Lang: Go
  Description : Bridges push notifications from ofono to telepathy-ofono

 Nuntium is a Lomiri component for MMS message processing.
 .
 Nuntium registers a push agent with ofono and handles the MMS workflow
 by bridging with telepathy-ofono.
 .
 The package also comes with useful tools for working with MMS and
 nuntium.
 .
   - Decode m-retrieve.conf messages
   - Stub an ofono push notification into nuntium.
 .
 This package will be maintained by the Debian UBports Packaging Team.

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

[gregor herrmann]

On Thu, 10 Apr 2025 07:37:32 +0200, Helmut Grohne wrote:


I sorted those logs and
you may now find them at
https://people.debian.org/~helmutg/glibc-no-crypt/logs/.


Thanks.


Beyond that, 11
packages build a perl extension module for testing purposes and
therefore need "Build-Depends: perl-xs-dev ".


I learned something new :)


For the perl-related changes we
might skip filing the bugs and consider mass-committing the changes for
a later upload.


At first glance that sounds reasonable (and save us from the work of 
correlating and closing bugs in packages). At second glance, i.e. 
after looking at 
, 
I note that many packages there don't match the 'lib.+-perl' pattern, 
i.e. are not maintained by the Debian Perl Team, and from the 
remaining ones, (without checking them) I also don't recognize quite 
a few package names. ¹


I think the "mass" for "mass-commiting" would not be high enough to 
rely on this mechanism, so I guess including them in the MBF makes 
more sense.



Cheers,
gregor


¹ I'm not surprised that this problem mainly affects 
non-team-maintained packages, as we've been using perl-xs-dev since 
quite some time …


--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

[Marco d'Itri]

On Apr 10, Helmut Grohne  wrote:


how about libc6-dev stops depending on libcrypt-dev?

Sure.


material of course. Also libc6-dev would still "Recommends:
libcrypt-dev", but libcrypt-dev would no longer be build-essential.

What purpose would this Recommends solve?


Assuming "no" and "yes" as answers, I'd like to proceed with mass bug
filing. I propose severity normal for all bugs. The additional

Go for it, great job!
Removing the package from the build-essential set is a worthwhile goal.

But please mention prominently that there is no need to work on this 
before the release.


--
ciao,
Marco


signature.asc
Description: PGP signature

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

[Santiago Vila]

[ Thanks for this. Awesome work! ]

El 10/4/25 a las 11:43, Helmut Grohne escribió:

My thinking here was to reduce the annoyance for users by degrading the
dependency softly. I was told that some users expect to be able to build
perl extensions without installing libperl-dev (which is why libperlVER
contains the headers that #include ). If we were right dropping
the dependency, libcrypt-dev could be automatically be removed from
those systems and we'd get angry bug reports. Going to Recommends is a
means to limit the annoyance while still meeting the original goal.


On the other hand:

- A recommends will only have some effect for people not having
libcrypt-dev installed yet, so people upgrading from trixie to forky
who have both libc6-dev and libcrypt-dev installed will not see the
libcrypt-dev package mysteriously removed from their systems.

- In general, Debian users are already aware that all sorts of breakage in
unstable is expected to happen shortly after a stable release, so I would
not really expect angry bugs about this from users.

So, I agree with Marco that Recommends is not necessary.

For the purposes of being nice to people, I would maybe extend
the period where the bugs are not RC as necessary so that we don't
introduce a lots of RC bugs at once (i.e. raise to serious not
in a date-based scheme but when the number of bugs is low enough).

Thanks.

Bug#1102559: ITP: golang-gitlab-ubports-development-core-go-ldm -- Go bindings for the Lomiri Download Manager

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-gitlab-ubports-development-core-go-ldm
  Version : 0.3
  Upstream Contact: UBports developers 
* URL : https://gitlab.com/ubports/development/core/go-ldm
* License : GPL-3
  Programming Lang: Go
  Description : Go bindings for the Lomiri Download Manager

 After importing this package you will be able to use the Lomiri Download
 Manager from golang directly.
 .
 This package will be maintained by the UBports Debian Packaging Team.

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

[Simon McVittie]

On Thu, 10 Apr 2025 at 07:37:32 +0200, Helmut Grohne wrote:

how about libc6-dev stops depending on libcrypt-dev?


I think this is a good idea for early in the forky cycle.


I also investigated
all apt-cache rdepends libcrypt1. That results in 151 source packages.

...

* steam-installer


This particular one is a false positive, it hard-codes a dependency on 
libcrypt1 (or more precisely libcrypt1 | libc6 (<< 2.29-4)) as one of 
the SONAMEs that Steam relies on the host system to provide (because it 
was historically part of glibc). It shouldn't need a -dev build-dependency 
for this purpose.


smcv

Re: Call for help: Dart/flutter & yubico-authenticator

[Thomas Goirand]

On 4/9/25 22:16, Patrick Winnertz wrote:

Hey,

Yubico has recently published it's EOL notification for the yubikey- 
manager gui [1]. The yubioath-desktop version which we ship within 
debian is already >3 years outated (and EOL) as yubico started to 
rewrite the app in flutter [2]. There is a also a RFP for flutter from 
2019, but nobody seems to care or to work on [3].


Over the time this new yubioath-flutter gui was renamed to yubico 
authenticator and all (or almost all) functionality of the yubikey- 
manager gui was added. [4] The EOL notification for the old gui is 
(sadly) the next logical step.


Due to missing dependencies (e.g. dart language [5], flutter [6])
  we are currently unable to ship the new app. This looks at a first 
glance as a bunch of work, which I can't handle alone. For me it looks 
like as if a complete new programming language + gui framework needs to 
be packaged + a lot of dart packages as dependencies.


==
To sum it up:
Debian will be no longer able to ship a upstream maintained gui 
configurator for a security related device, which is also broadly used 
by fellow DDs. To change the situation a new programming language + gui 
framework needs to be packaged.


Any suggestions/help on how to improve this miserable situation is 
appreciated.


IMO, this isn't as miserable as you are saying. Unless I missed 
something, there's still the command line thingy that works quite well, no?


Cheers,

Thomas Goirand (zigo)

Bug#1102583: ITP: cpr -- cpr is a simple wrapper around libcurl inspired by python requests

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 
X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org

  Package name: cpr
  Version : 1.11.2
  Upstream Contact: Fabian Sauter 
  URL : https://docs.libcpr.org/
  License : MIT
  Programming Lang: C++
  Description : cpr is a simple wrapper around libcurl inspired by python
requests

Re: "Missing" entries in timezone tables

[Michael Stone]

On Tue, Apr 08, 2025 at 12:08:05PM -0500, Richard Laager wrote:
I got bit (not in pytz) by US/Pacific disappearing, so I understand 
the annoyance from the user perspective. However, as that is what has 
happening in tzdata, I don't think we should have individual packages 
trying to fight that individually/haphazardly.


If you're maintaining a package that itself is trying to maintain 
compatibility, what else would you do? As the NEWS related to 
tzdata-legacy itself says:


Please install tzdata-legacy in case you need the legacy timezones or to
restore the previous behavior. This might be needed in case the system
provides timezone-aware data over the network (e. g. SQL databases).


If you patch US/Pacific back in manually, then you have two problems:

1. Things are inconsistent. For example, US/Pacific works in Python, 
but not in systemd. (I realize that's the state that upstream pytz is 
creating already, but you needn't follow them down this road.)


Why would it not work in systemd? I'd argue that any inconsistency would 
be to have debian's pytz needlessly diverge from its expected functionality.


2. You will never know when it's acceptable to remove these, so you'll 
feel stuck carrying that forever. (On the other hand, you are just 
following upstream pytz, so you can say it's their problem. But, they 
will definitely have this same problem of not knowing when to remove 
the backwards compatibility.)


Yeah, that's how backward compatibility works. I don't see the problem 
at the cost of a few symlinks.

Bug#1102291: ITP: lib1305 -- microlibrary for the Poly1305 one-time authenticator

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: lib1305
  Version : 20250407
  Upstream Author : Kaushik Nath, Daniel J. Bernstein, et al
* URL : https://lib1305.cr.yp.to/
* License : public domain
  Programming Lang: C
  Description : microlibrary for the Poly1305 one-time authenticator

 lib1305 is a microlibrary for the Poly1305 one-time authenticator.

https://salsa.debian.org/debian/lib1305

/Simon


signature.asc
Description: PGP signature

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

[Helmut Grohne]

Hi Marco,


On Thu, Apr 10, 2025 at 11:01:24AM +0200, Marco d'Itri wrote:
> On Apr 10, Helmut Grohne  wrote:
> > how about libc6-dev stops depending on libcrypt-dev?
> Sure.

Thanks for the feedback.

> > material of course. Also libc6-dev would still "Recommends:
> > libcrypt-dev", but libcrypt-dev would no longer be build-essential.
> What purpose would this Recommends solve?

My thinking here was to reduce the annoyance for users by degrading the
dependency softly. I was told that some users expect to be able to build
perl extensions without installing libperl-dev (which is why libperlVER
contains the headers that #include ). If we were right dropping
the dependency, libcrypt-dev could be automatically be removed from
those systems and we'd get angry bug reports. Going to Recommends is a
means to limit the annoyance while still meeting the original goal.

This is not to be read as an endorsement of libc6-dev permanently
recommending libcrypt-dev. For instance downgrading it to Suggests or
dropping it entirely could be an option for later. To me, the key
feature here is making it removable in the first place.

In any case, I'll leave this particular aspect to the glibc and
libxcrypt maintainers. If you feel, Recommends is not warranted, so be
it.

Helmut

Bug#1102342: ITP: python-lib1305 -- Python wrapper around microlibrary for the Poly1305 one-time authenticator

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-lib1305
  Version : 20250407.1
  Upstream Contact: Jan Mojzis 
* URL : https://github.com/janmojzis/python-lib1305
* License : CC0
  Programming Lang: Python
  Description : Python wrapper around microlibrary for the Poly1305 
one-time authenticator

Python wrapper around implementation of the Poly1305 one-time authenticator.
The Python API for lib1305 provides the functions:
poly1305.auth()
poly1305.verify()

The library has a very simple stateless API.
As an example, the following script generates an authenticator 'a'
given a message 'm' and a secret key 'k'. And verifies an authenticator 'a'
given a message 'm' and a secret key 'k'.

from lib1305 import poly1305
a = poly1305.auth(m, k)
poly1305.verify(a, m, k)

This package is related to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102291

I'm going to maintain the package using https://salsa.debian.org/
It is being prepared here: https://salsa.debian.org/janmojzis/python-lib1305

Jan

Re: Call for help: Dart/flutter & yubico-authenticator

[Patrick Winnertz]

Hey Thomas,


IMO, this isn't as miserable as you are saying. Unless I missed 
something, there's still the command line thingy that works quite well, no?


You're right - the cmd command is still there and it's not EOL. That's 
why I wrote in the mail "gui configurator". I know that your're able to 
do basically everything with the ykman command (I personally do use it) 
- but if we're losing all graphical interfaces for the yubikeys we'll 
lock out in my eyes quite a lot of people. The only option for these 
people is to install packages via flatpak.


More and more packages/programs are just available using flatpak/co and 
I really dislike that trend.


With best regards
Patrick

--
 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  win...@debian.org/patr...@winnertz.eu
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43
 ⠈⠳⣄

The people who refer to the pandemic in the past tense and climate 
change in the future tense are the reason everything is going to shit.




OpenPGP_0xC6D50A4188C70E43.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal: drop libcrypt-dev dependency from libc6-dev

[Aurelien Jarno]

Hi,

On 2025-04-10 07:37, Helmut Grohne wrote:
> Hello fellow developers,

[ Snip ]

> Question 1: Do you see important aspects missed in this analysis?

No

> Question 2: Do you agree that this change is worth the effort?

I don't know. I do not see a huge benefit from the glibc point of view, 
but I understand that it could be a benefit for other parts of Debian. 
As long as these other part leads the effort that sounds good.

> Assuming "no" and "yes" as answers, I'd like to proceed with mass bug 
> filing. I propose severity normal for all bugs. The additional 
> dependencies can be piggy-backed onto uploads aimed for trixie as their 
> risk of causing breakage is really low. For the perl-related changes we 
> might skip filing the bugs and consider mass-committing the changes for 
> a later upload. The glibc change must not be done during the trixie 
> cycle, but can happen early in the forky one. At that point, the 
> remaining bugs would become RC.

It seems to me that this way of doing might block glibc development, ie 
prevent glibc from migrating to testing for many weeks, as I guess it 
will causes autopkgtest failures in addition to FTBFS.

I think we should proceed with the change on the glibc side once we know 
that the bugs can be be solved *in testing* in a reasonable time frame. 
This could mean massive NMUs to fix the remaining issues (but this could 
be seen as aggressive). An other option is to upgrade the severity to 
serious before the change on the glibc side, which should remove most 
unfixed packages from testing within 1 month, and the remaining packages 
can be fixed through NMU.

> Question 3: Can I move forward with the MBF?

Sounds good to me. Whatever is decided, having an explicit dependency is 
always better, than relying on de facto build-essential.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1102367: ITP: node-tldts -- JavaScript library to extract fields from URLs

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-devel@lists.debian.org, y...@debian.org

* Package name: node-tldts
  Version : 6.1.85
  Upstream Contact: Rémi Berson 
* URL : https://github.com/remusao/tldts
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript library to extract fields from URLs

node-tldts is a JavaScript library to extract hostnames, domains, public
suffixes, top-level domains and subdomains from URLs.
It's tuned for performane, handles both URLs and hostnames, supports full
Unicode/IDNA, can parse email addresses, detects IPv4 and IPv6 addresses,
has small bundles and small memory footprint and is fully tested.

node-tldts is a new dependency of node-tough-cookie >= 5. It will be
maintained under JS Team umbrella.