Bug#1065536: ITP: python-bluetooth-adapters -- Enumerate and find Bluetooth Adapters in Python

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-bluetooth-adapters
  Version : 0.18.0
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bluetooth-devices/bluetooth-adapters
* License : MIT
  Programming Lang: Python
  Description : Enumerate and find Bluetooth Adapters in Python

  Provides tools for enumerating and identifying available Bluetooth adapters.
  Facilitates the detection and interaction with various Bluetooth adapters,
  aiding in the development of applications requiring Bluetooth communication.
  .
  Features include:
- discovering Bluetooth adapters
- adapter details
- perform scans for devices
- manage Bluetooth connections

I plan to maintain this package as part of the Python team.

Bug#1065537: ITP: bleak-retry-connector -- Connector for Bleak Clients that handles transient connection failures

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: bleak-retry-connector
  Version : 3.4.0
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bluetooth-devices/bleak-retry-connector
* License : MIT
  Programming Lang: Python
  Description : Connector for Bleak Clients that handles transient 
connection failures

  Provides a robust connector for Bleak clients, aimed at enhancing Bluetooth
  communication stability in Python applications. Intelligently handles
  transient connection failures by implementing retry mechanisms, thereby
  improving the reliability of Bluetooth connections. Designed for developers
  working on Bluetooth applications, simplifies the process of managing
  connections to BLE devices, especially in environments where connectivity may
  be prone to interruptions.
  .
  Key features include:
  .
- Automatic retry on connection failure, reducing the need for manual
  reconnection logic.
- Configurable retry attempts and backoff strategies, allowing for
  customisation based on specific use case requirements.
- Compatibility with the latest versions of Bleak, ensuring up-to-date
  support for BLE communication.
- Easy integration into existing Python projects using Bleak for Bluetooth
  communication.

I plan to maintain this package as part of the Python team.

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Vincent Lefevre]

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > However it's true that some packages are installed before that, at the 
> > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
> 
> Correct.  This is tracked as bug#742977

Bug#742977 is about whether to mark installed packages as
auto-installed or not. It is not about Recommends.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Jonas Smedegaard]

Quoting Vincent Lefevre (2024-03-06 12:17:55)
> On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> > Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > > However it's true that some packages are installed before that, at the 
> > > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
> > 
> > Correct.  This is tracked as bug#742977
> 
> Bug#742977 is about whether to mark installed packages as
> auto-installed or not. It is not about Recommends.

Sorry. You are right, of course.

It is another related issue.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Perl problem - loadable library and perl binaries are mismatched

[gregor herrmann]

On Tue, 05 Mar 2024 23:55:28 +0100, John Paul Adrian Glaubitz wrote:

> Also, I noticed that libxs-parse-keyword-perl build-depends on 
> libextutils-cbuilder-perl
> which is apparently obsolete and also still depends on the old Perl API [1] 
> which makes
> me wonder how libxs-parse-keyword-perl was built for armhf and armel [2].
> 
> Adrian
> 
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060712
> > [2] 
> > https://buildd.debian.org/status/package.php?p=libxs-parse-keyword-perl&suite=sid

libextutils-cbuilder-perl is (not only a separate package but also)
Provided by perl.

Cheers,
gregor 

-- 
 .''`.  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

Bug#1065550: ITP: regressi -- Software to manage experimental data

[Georges Khaznadar]

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

* Package name: regressi
  Version : 4.8.1
  Upstream Contact: Jean Michel Millet 
* URL : https://regressi.fr/
* License : GPL-3+
  Programming Lang: (Pascal (fpc)
  Description : Software to manage experimental data

 Regressi can be used to manage experimental data, while teaching
 science in secondary schools and universities. It features fitting
 experimental data with classic or custom models, creating simulated
 data from models. It can also be used to interactively retreive data
 from recorded video files.


This package will be maintained under the umbrella of science-team,
there is a repository at https://salsa.debian.org/science-team/regressi

openssl 3.1.5-1.1 effect on reverse dependencies

[Otto Kekäläinen]

Hi Benjamin!

You recently uploaded openssl 3.1.5-1.1.

Are you tracking the effect it had on reverse dependencies?
Do you have plans to do any follow-up uploads or +b1 rebuilds of other packages?

For example curl is unable to satisfy build dependencies on
armhf/armel at the moment:

https://buildd.debian.org/status/package.php?p=curl&suite=sid

curl build-depends on:
- libssl-dev:armhf
libssl-dev depends on:
- libssl3t64:armhf (= 3.1.5-1.1)
curl build-depends on:
- libssl-dev:armhf
libssl-dev depends on:
- libssl3t64:armhf (= 3.1.5-1.1)
libssl3t64 depends on:
-
libssl3t64 conflicts with:
- libssl3:armhf (< 3.1.5-1.1)

Re: openssl 3.1.5-1.1 effect on reverse dependencies

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 07:47:57AM -0800, Otto Kekäläinen wrote:
> Hi Benjamin!
> 
> You recently uploaded openssl 3.1.5-1.1.
> 
> Are you tracking the effect it had on reverse dependencies?
That's just a part of the time64 transition and it's definitely tracked by
people.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065555: ITP: golang-github-upper-db -- Data access layer for PostgreSQL, CockroachDB, MySQL, SQLite and MongoDB with ORM-like features

[tous]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Owner: tous 

* Package name: golang-github-upper-db
  Version : 4.6.0-1
  Upstream Author : upper.io
* URL : https://github.com/upper/db
* License : MIT License
  Programming Lang: Go
  Description : Data access layer for PostgreSQL, CockroachDB, 
MySQL, SQLite and MongoDB with ORM-like features


 upper/db is a productive data access layer (DAL) for Go
 that provides agnostic tools to work with different data sources, such 
as:

  * PostgreSQL (https://upper.io/v4/adapter/postgresql)
  * MySQL (https://upper.io/v4/adapter/mysql)
  * MSSQL (https://upper.io/v4/adapter/mssql)
  * CockroachDB (https://upper.io/v4/adapter/cockroachdb)
  * MongoDB (https://upper.io/v4/adapter/mongo)
  * QL (https://upper.io/v4/adapter/ql)
  * SQLite (https://upper.io/v4/adapter/sqlite)

 This package is a dependency of probe-cli

Bug#1065557: ITP: golang-modernc-db -- implements some data structures found in database implementations

[tous]

Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Severity: wishlist
Owner: tous 

* Package name: golang-modernc-db
  Version : 1.0.10-1
  Upstream Author : Jan Mercl
* URL : https://gitlab.com/cznic/db
* License : BSD-3-clause
  Programming Lang: Go
  Description : implements some data structures often found in 
databases


Package DB implements some data structures found in database 
implementations. (Work in Progress)


This package is on dependency tree of probe-cli.

Bug#1065558: ITP: golex -- a lex/flex like utility

[tous]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

Owner: tous 

* Package name: golex
  Version : 1.1.0-1
  Upstream Author : Jan Mercl
* URL : https://gitlab.com/cznic/golex
* License : BSD-3-clause
  Programming Lang: Go
  Description : a lex/flex like (not fully POSIX lex compatible) 
utility


Golex is a lex/flex like (not fully POSIX lex compatible) utility. It 
renders .l formated data
to Go source code. The .l data can come from a file named in a command 
line argument.

If no non-opt args are given, golex reads stdin.

This package is on dependency tree of probe-cli

Bug#1065559: ITP: golang-modernc-lexer -- provides generating actionless scanners at run time

[tous]

Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Severity: wishlist
Owner: tous 

* Package name: golang-modernc-lexer
  Version : 1.0.5-1
  Upstream Author : Jan Mercl
* URL : https://gitlab.com/cznic/lexer
* License : BSD-3-clause
  Programming Lang: Go
  Description : lexer provides generating actionless scanners at run 
time


Scanners are defined by regular expressions and/or lexical grammars, 
mapping between those definitions, token numeric identifiers
and an optional set of starting id sets, providing simmilar 
functionality as switching start states in *nix LEX. The generated FSMs 
are
Unicode arune based and all unicode.Categories and unicode.Scripts are 
supported by the regexp syntax using the \p{name} construct.


This package is on dependency tree of probe-cli

Bug#1065560: ITP: golang-modernc-lex -- provides support for a *nix (f)lex like tool on .l sources

[tous]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Owner: tous 

* Package name: golang-modernc-lex
  Version : 1.1.1-1
  Upstream Author : Jan Mercl
* URL : https://gitlab.com/cznic/lex
* License : BSD-3-clause
  Programming Lang: Go
  Description : lex provides support for a *nix (f)lex like tool on 
.l sources


Package lex provides support for a *nix (f)lex like tool on .l sources.

This package is on dependency tree of probe-cli

Bug#1065568: ITP: golang-modernc-file -- write ahead log in Go

[tous]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Owner: tous 

* Package name: golang-modernc-file
  Version : 1.0.8-1
  Upstream Author : Jan Mercl
* URL : https://gitlab.com/cznic/file
* License : BSD-3-clause
  Programming Lang: Go
  Description : write ahead log in Go

Package file handles write-ahead logs and space management of 
os.File-like entities.


This package is on dependency tree of probe-cli

Re: Re: Perl problem - loadable library and perl binaries are mismatched

[John Paul Adrian Glaubitz]

Hi Roderich,

On Wed, 2024-03-06 at 19:20 +0100, Roderich Schupp wrote:
> Hi,
> 
> > Parser.c: loadable library and perl binaries are mismatched (got first 
> > handshake key 0xb600080, needed 0xb700080)
> > 
> 
> 
> The upper 16 bits in these keys (i.e. 0xb60 vs 0xb70) is 
> sizeof(PerlInterpreter), the one that some XS module saw
> when it was built vs the size your current perl executable was built with. 
> From the location of the error message
> it looks as the build process ("perl Build") has just created the "glue" 
> shared library (blib/arch/auto/XS/Parse/
> Keyword/Keyword.so), next it is going to generate documentation (man pages). 
> Unless there's an error warning,
> this doesn't produce any output. I ran "perl Build" under strace, this shows 
> that doc generation loads Pod::Html
> (probably to generate HTML pages as well, though none were requested) and 
> finally this loads HTML::Parser. The
> latter is an XS module 
> (/usr/lib/x86_64-linux-gnu/perl5/5.38/auto/HTML/Parser/Parser.so) and seems 
> to emit the
> above message.
> 
> So the reason is that your HTML/Parser/Parser.so (maybe a version not in the 
> canonical path?)  is built with a
> different struct PerlInterpreter. The difference in sizeof(PerlInterpreter) 
> can probably explained with the
> time64 transition as PerlInterpreter contains a struct stat.

Thanks a lot for the detailed analysis. In fact, libhtml-parser-perl has not 
been rebuilt against the time64_t
Perl package yet [1] which would align with your explanation. I'll try to 
rebuild the package locally and if
it fixes the problem, I'll binNMU it for powerpc.

Your explanation will enable me to debug future occurrences as I now understand 
the underlying problem.

Thanks,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=libhtml-parser-perl

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: 64-bit time_t transition in progress in unstable

[Kevin Bowling]

On Mon, Feb 26, 2024 at 4:21 PM Steve Langasek  wrote:
>
> Dear developers,
>
> With the last known blockers resolved, I have now uploaded NMUs of the
> experimental versions of gcc-13 and gcc-14 to unstable, and a corresponding
> upload of dpkg changing the default build flags is expected to follow soon,
> probably within the day.
>
> As a result, the 64-bit time_t transition is now in progress in unstable.
>
> If your packages are any of the lists of those affected by the time_t ABI
> transition[0][1][2][3], it may be advisable to hold off uploads to unstable
> for the next few days in order to avoid any sort of accidental ABI skew on
> armel/armhf.
>
> And if your package is in the list of those requiring sourceful changes for
> the transition due to library package renames[0][1], PLEASE take care not to
> make uploads to unstable clobbering the NMUS and reverting the package
> renaming.  In case you missed it previously, dd-list output saying whether
> you have a package that is affected can be found at [4].
>
> To avoid pain for porters, the mass NMUs to unstable will only be started
> once gcc-13 and dpkg have been built on our 32-bit ports per
> .
>
> As a reminder, the wiki page for the release goal is here:
>
>https://wiki.debian.org/ReleaseGoals/64bit-time
>
> See also the various threads on debian-devel for a more in-depth accounting
> of the work up to this point.[5]

Are there instructions on how to progress an unstable system through
this, or is the repo currently in a known inconsistent state?  I have
tried upgrading various packages to work through deps but I am unable
to do a dist-upgrade for a while.

>
> Thanks,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world

Re: 64-bit time_t transition in progress in unstable

[Russ Allbery]

Kevin Bowling  writes:

> Are there instructions on how to progress an unstable system through
> this, or is the repo currently in a known inconsistent state?  I have
> tried upgrading various packages to work through deps but I am unable to
> do a dist-upgrade for a while.

It doesn't look like the migration is finished yet, so this is expected.
There are a whole lot of packages that need to be rebuilt and a whole lot
of libraries, so some edge cases will doubtless take a while to sort out.

-- 
Russ Allbery (r...@debian.org)  

Re: 64-bit time_t transition in progress in unstable

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote:
> Are there instructions on how to progress an unstable system through
> this, or is the repo currently in a known inconsistent state?  I have
> tried upgrading various packages to work through deps but I am unable
> to do a dist-upgrade for a while.
Being unable to do a dist-upgrade is expected and some packages can't be
installed or can't be upgraded, but in general on amd64 you should be able
to upgrade a majority of them with `apt upgrade` and then manual
installing/upgrading, if you wish so (as in theory most libfoo0t64 are
drop-in replacements for libfoo0, but in practice some packages have
additional abi deps for their plugins etc., plus the usual amd64-i386
skews, plus some unique problems in some packages).
Also debootstrapping sid is broken, or may be broken from time to time.
Install testing instead if that's good enough.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: openssl 3.1.5-1.1 effect on reverse dependencies

[Micha Lenk]

Hi all,

Am 6. März 2024 17:05:15 MEZ schrieb Andrey Rahmatullin :
>On Wed, Mar 06, 2024 at 07:47:57AM -0800, Otto Kekäläinen wrote:
>> Hi Benjamin!
>> 
>> You recently uploaded openssl 3.1.5-1.1.
>> 
>> Are you tracking the effect it had on reverse dependencies?
>That's just a part of the time64 transition and it's definitely tracked by
>people.


Yet I wonder how I as a maintainer of a (transitive) reverse dependency can 
assist in any meaningful way. Are we supposed to do something about the current 
situation? Or is some central piece already being worked on and no parallel, 
shared maintenance possible?

Cheers,
Micha

Bug#1065572: ITP: llm -- Access large language models from the command-line

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
debian...@lists.debian.org

* Package name: llm
  Version : 0.13.1
  Upstream Contact: Simon Willison 
* URL : https://llm.datasette.io/
* License : Apache-2.0
  Programming Lang: Python
  Description : CLI utility and Python library for interacting
  with Large Language Models

A CLI utility and Python library for interacting with Large Language
Models, both via remote APIs and models that can be installed and run
on your own machine.

Run prompts from the command-line, store the results in SQLite,
generate embeddings and more.



So there has been some discussions about packaging LLM things in
Debian, and this is my stab at opening a discussion about *what*
exactly, we *can* package, right now.

LLM is a (possibly poorly named) package that allows users to interact
with various language models. Its primary target is obviously the
OpenAI API (it's the example in the "Quick Start"), but it also
supports local models like Llama 2, Ollama, and MLC, and other online
models like Claude, GEmini and Mistral.

I *think* this belongs in contrib, because it *mostly* relies on
non-free software (and services) to do its thing, but I'd be happy to
move that around.

I need this because I was using GPT plus for a while and now I'm
switching to the API to cut down on costs.

Re: 64-bit time_t transition in progress in unstable

[Steve Langasek]

On Thu, Mar 07, 2024 at 12:46:24AM +0500, Andrey Rahmatullin wrote:
> On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote:
> > Are there instructions on how to progress an unstable system through
> > this, or is the repo currently in a known inconsistent state?  I have
> > tried upgrading various packages to work through deps but I am unable
> > to do a dist-upgrade for a while.
> Being unable to do a dist-upgrade is expected and some packages can't be
> installed or can't be upgraded, but in general on amd64 you should be able
> to upgrade a majority of them with `apt upgrade` and then manual
> installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> drop-in replacements for libfoo0, but in practice some packages have
> additional abi deps for their plugins etc., plus the usual amd64-i386
> skews, plus some unique problems in some packages).
> Also debootstrapping sid is broken, or may be broken from time to time.
> Install testing instead if that's good enough.

Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
actually would expect unstable to be dist-upgradeable on non-32-bit archs:
either the existing non-t64 library will be kept installed because nothing
yet needs the t64 version, or something does want the t64 version and apt
will accept it as a replacement for the non-t64 version because it Provides:
the non-t64 name.

So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
NOT working, I think we should want to see some apt output showing what's
not working.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > Are there instructions on how to progress an unstable system through
> > > this, or is the repo currently in a known inconsistent state?  I have
> > > tried upgrading various packages to work through deps but I am unable
> > > to do a dist-upgrade for a while.
> > Being unable to do a dist-upgrade is expected and some packages can't be
> > installed or can't be upgraded, but in general on amd64 you should be able
> > to upgrade a majority of them with `apt upgrade` and then manual
> > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > drop-in replacements for libfoo0, but in practice some packages have
> > additional abi deps for their plugins etc., plus the usual amd64-i386
> > skews, plus some unique problems in some packages).
> > Also debootstrapping sid is broken, or may be broken from time to time.
> > Install testing instead if that's good enough.
> 
> Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> either the existing non-t64 library will be kept installed because nothing
> yet needs the t64 version, or something does want the t64 version and apt
> will accept it as a replacement for the non-t64 version because it Provides:
> the non-t64 name.
> 
> So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> NOT working, I think we should want to see some apt output showing what's
> not working.
On my system there is currently only one problem not related to libuuid:
vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
uuid, I have several i386 libraries installed that depend on it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Steve Langasek]

On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote:
> On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > > Are there instructions on how to progress an unstable system through
> > > > this, or is the repo currently in a known inconsistent state?  I have
> > > > tried upgrading various packages to work through deps but I am unable
> > > > to do a dist-upgrade for a while.
> > > Being unable to do a dist-upgrade is expected and some packages can't be
> > > installed or can't be upgraded, but in general on amd64 you should be able
> > > to upgrade a majority of them with `apt upgrade` and then manual
> > > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > > drop-in replacements for libfoo0, but in practice some packages have
> > > additional abi deps for their plugins etc., plus the usual amd64-i386
> > > skews, plus some unique problems in some packages).
> > > Also debootstrapping sid is broken, or may be broken from time to time.
> > > Install testing instead if that's good enough.

> > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> > actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> > either the existing non-t64 library will be kept installed because nothing
> > yet needs the t64 version, or something does want the t64 version and apt
> > will accept it as a replacement for the non-t64 version because it Provides:
> > the non-t64 name.

> > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> > NOT working, I think we should want to see some apt output showing what's
> > not working.
> On my system there is currently only one problem not related to libuuid:
> vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
> uuid, I have several i386 libraries installed that depend on it.

That seems like a case where the maintainer (cc:ed) could add the
vlc-plugin-abi-3-0-0f Provides: on 64-bit archs for backwards-compatibility
to unblock.  Or someone can just request binNMUs for this package sooner
rather than later.  (It's premature to request mass binNMUs yet while arm*
are still being re-bootstrapped.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1065576: ITP: python-ulid -- Universally unique lexicographically sortable identifier (Python library)

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-ulid
  Version : 2.2.0
  Upstream Contact: Martin Domke 
* URL : https://python-ulid.rtfd.io/
* License : MIT
  Programming Lang: Python
  Description : Universally unique lexicographically sortable identifier 
(Python library)

A ULID is a universally unique lexicographically sortable
identifier. It is:

- 128-bit compatible with UUID
- 1.21e+24 unique ULIDs per millisecond
- Lexicographically sortable!
- Canonically encoded as a 26 character string, as opposed to the 36 character 
UUID
- Uses Crockford's base32 for better efficiency and readability (5 bits per 
character)
- Case insensitive
- No special characters (URL safe)



This is a dependency for the llm package (#1065572). We have another
ULID implementation in Debian (golang-github-oklog-ulid-dev) but it's
not sufficient for the LLM package, which expects the Python library.

This is going to be packaged in the Python team.

Re: 64-bit time_t transition in progress in unstable

[Sebastian Ramacher]

On 2024-03-06 12:53:02 -0800, Steve Langasek wrote:
> On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote:
> > On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > > > Are there instructions on how to progress an unstable system through
> > > > > this, or is the repo currently in a known inconsistent state?  I have
> > > > > tried upgrading various packages to work through deps but I am unable
> > > > > to do a dist-upgrade for a while.
> > > > Being unable to do a dist-upgrade is expected and some packages can't be
> > > > installed or can't be upgraded, but in general on amd64 you should be 
> > > > able
> > > > to upgrade a majority of them with `apt upgrade` and then manual
> > > > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > > > drop-in replacements for libfoo0, but in practice some packages have
> > > > additional abi deps for their plugins etc., plus the usual amd64-i386
> > > > skews, plus some unique problems in some packages).
> > > > Also debootstrapping sid is broken, or may be broken from time to time.
> > > > Install testing instead if that's good enough.
> 
> > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, 
> > > I
> > > actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> > > either the existing non-t64 library will be kept installed because nothing
> > > yet needs the t64 version, or something does want the t64 version and apt
> > > will accept it as a replacement for the non-t64 version because it 
> > > Provides:
> > > the non-t64 name.
> 
> > > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade 
> > > is
> > > NOT working, I think we should want to see some apt output showing what's
> > > not working.
> > On my system there is currently only one problem not related to libuuid:
> > vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
> > uuid, I have several i386 libraries installed that depend on it.
> 
> That seems like a case where the maintainer (cc:ed) could add the
> vlc-plugin-abi-3-0-0f Provides: on 64-bit archs for backwards-compatibility
> to unblock.  Or someone can just request binNMUs for this package sooner
> rather than later.  (It's premature to request mass binNMUs yet while arm*
> are still being re-bootstrapped.)

The Provides in this case would not be enough as it directly maps to the
symbol postfix used by the plugin loader. I'd also need the
corresponding #ifdef to only switch the symbol postfix on the affected
architectures.

Cheers
-- 
Sebastian Ramacher

Re: openssl 3.1.5-1.1 effect on reverse dependencies

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 08:50:59PM +0100, Micha Lenk wrote:
> >> You recently uploaded openssl 3.1.5-1.1.
> >> 
> >> Are you tracking the effect it had on reverse dependencies?
> >That's just a part of the time64 transition and it's definitely tracked by
> >people.
> 
> 
> Yet I wonder how I as a maintainer of a (transitive) reverse dependency
> can assist in any meaningful way. Are we supposed to do something about
> the current situation? Or is some central piece already being worked on
> and no parallel, shared maintenance possible?
If the only thing your package need is a binNMU or even nothing then you
don't need to do anything.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Perl problem - loadable library and perl binaries are mismatched

[Steve Langasek]

On Tue, Mar 05, 2024 at 11:55:28PM +0100, John Paul Adrian Glaubitz wrote:
> > Thanks! You saved me a lot of headaches!

FWIW to do a bootstrap build of perl I had to:

 - disable libdb and libgdbm build-deps
 - disable build-time tests, which would pick up old ndbm module from
   on-disk and break as a result

Not sure if your bootstrap path was similar.

> I have run into this issue again trying to rebuild libxs-parse-keyword-perl
> with a src:perl that was built with dpkg_1.22.5:

> powerpc-linux-gnu-gcc -Isrc/ -I/usr/lib/powerpc-linux-gnu/perl/5.38/CORE 
> -DVERSION="0.39" -DXS_VERSION="0.39" -fPIC -I. -Ihax -c -D_REENTRANT 
> -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 
> -Werror=implicit-function-declaration 
> -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=. 
> -fstack-
> protector-strong -Wformat -Werror=format-security -g -O2 
> -Werror=implicit-function-declaration 
> -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=. 
> -fstack-protector-strong -
> Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -o lib/XS/Parse/Keyword.o 
> lib/XS/Parse/Keyword.c
> ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/XS/Parse/Keyword/Keyword.bs')
> powerpc-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=. 
> -fstack-protector-strong -Wformat -Werror=format-
> security -Wl,-z,relro -Wl,-z,now -shared -L/usr/local/lib 
> -fstack-protector-strong -o blib/arch/auto/XS/Parse/Keyword/Keyword.so 
> lib/XS/Parse/Keyword.o src/infix.o src/keyword.o
> Parser.c: loadable library and perl binaries are mismatched (got first 
> handshake key 0xb600080, needed 0xb700080)
> dh_auto_build: error: /usr/bin/perl Build returned exit code 1
> make: *** [debian/rules:6: binary-arch] Error 1
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2

I did not run into this.  Do you have a mix of old and new packages from
perl source installed?

> Also, I noticed that libxs-parse-keyword-perl build-depends on
> libextutils-cbuilder-perl which is apparently obsolete and also still
> depends on the old Perl API [1] which makes me wonder how
> libxs-parse-keyword-perl was built for armhf and armel [2].

When modules are incorporated into perl, perl declares a provides: for them. 
There's no reason to install the libextutils-cbuilder-perl package anymore. 
(which, btw, was an arch: all package, so in any case it wouldn't be
affected by the ABI transition.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Russ Allbery]

Steve Langasek  writes:

> So once the libuuidt64 revert is done (later today?), if apt
> dist-upgrade is NOT working, I think we should want to see some apt
> output showing what's not working.

My current list of unupgradable packages on amd64 is:

gir1.2-gstreamer-1.0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libegl-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgbm1/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgl1-mesa-dri/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglapi-mesa/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglx-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgstreamer1.0-0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libldb2/unstable 2:2.8.0+samba4.19.5+dfsg-4 amd64 [upgradable from: 
2:2.8.0+samba4.19.5+dfsg-1]
libspa-0.2-modules/unstable 1.0.3-1.1 amd64 [upgradable from: 1.0.3-1]
libzvbi-common/unstable 0.2.42-1.2 all [upgradable from: 0.2.42-1.1]
mesa-va-drivers/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
samba-libs/unstable 2:4.19.5+dfsg-4 amd64 [upgradable from: 2:4.19.5+dfsg-1]

Doing a bit of exploration, the root problems seem to be:

 libdebuginfod1 : Depends: libelf1 (= 0.190-1+b1)
 libdw1 : Depends: libelf1 (= 0.190-1+b1)
 libxine2-misc-plugins : Depends: libsmbclient (>= 2:4.0.3+dfsg1)
 libgl1-mesa-dri : Depends: libglapi-mesa (= 24.0.1-1)

I'm not sure what's blocking the chain ending in libelf1 since t64
versions of those libraries seem to be available, but attempting to force
it would remove gdb and jupyter if that helps.

-- 
Russ Allbery (r...@debian.org)  

Bug#1065578: ITP: python-sqlite-migrate -- A simple database migration system for SQLite, based on sqlite-utils

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-sqlite-migrate
  Version : 0.1b0
  Upstream Contact: Simon Willison 
* URL : https://github.com/simonw/sqlite-migrate
* License : Apache-2.0
  Programming Lang: Python
  Description : A simple database migration system for SQLite, based on 
sqlite-utils

Python library to operate changes on SQLite database, based on
migration files.



This is a dependency of the LLM package (#1065572).

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

My current list of unupgradable packages on amd64 is:

gir1.2-gstreamer-1.0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libegl-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgbm1/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgl1-mesa-dri/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglapi-mesa/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglx-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgstreamer1.0-0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libldb2/unstable 2:2.8.0+samba4.19.5+dfsg-4 amd64 [upgradable from: 
2:2.8.0+samba4.19.5+dfsg-1]
libspa-0.2-modules/unstable 1.0.3-1.1 amd64 [upgradable from: 1.0.3-1]
libzvbi-common/unstable 0.2.42-1.2 all [upgradable from: 0.2.42-1.1]
mesa-va-drivers/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
samba-libs/unstable 2:4.19.5+dfsg-4 amd64 [upgradable from: 2:4.19.5+dfsg-1]

Doing a bit of exploration, the root problems seem to be:

 libdebuginfod1 : Depends: libelf1 (= 0.190-1+b1)
 libdw1 : Depends: libelf1 (= 0.190-1+b1)
 libxine2-misc-plugins : Depends: libsmbclient (>= 2:4.0.3+dfsg1)
 libgl1-mesa-dri : Depends: libglapi-mesa (= 24.0.1-1)

I'm not sure what's blocking the chain ending in libelf1 since t64
versions of those libraries seem to be available, but attempting to force
it would remove gdb and jupyter if that helps.


You can force the migration by explicitly adding the package that it 
propose to remove (e.g gdb for libelf, ...)


I managed to upgrade all packages you mention in your mail that way. 
Only libkf5akonadisearch-bin libkf5akonadisearch-plugins 
libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64 
libkf5akonadisearchxapian5t64 are missing because there are bugs in the 
Provides: for api /or the packe depending on the T64 ABI are not yet 
rebuild. I opened a bug for that



-- eric

Re: 64-bit time_t transition in progress in unstable

[Russ Allbery]

Eric Valette  writes:

> You can force the migration by explicitly adding the package that it
> propose to remove (e.g gdb for libelf, ...)

> I managed to upgrade all packages you mention in your mail that
> way. Only libkf5akonadisearch-bin libkf5akonadisearch-plugins
> libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64
> libkf5akonadisearchxapian5t64 are missing because there are bugs in the
> Provides: for api /or the packe depending on the T64 ABI are not yet
> rebuild. I opened a bug for that

Ah, yes, that worked.  It took some experimentation to figure out which
packages could be forced and which ones were causing removals.

I'm down to only libzvbi-common having problems, which I can't manage to
force without removing xine-ui.  If I attempt to install them both
together, I get this failure:

The following packages have unmet dependencies:
 libxine2 : Depends: libxine2-plugins (= 1.2.13+hg20230710-2) but it is not 
going to be installed or
 libxine2-misc-plugins (= 1.2.13+hg20230710-2+b3) but it is 
not going to be installed
 libxine2-ffmpeg : Depends: libavcodec60 (>= 7:6.0)
   Depends: libavformat60 (>= 7:6.0)

The apt resolver seems to be struggling pretty hard to make sense of the
correct upgrade path.

-- 
Russ Allbery (r...@debian.org)  

Re: 64-bit time_t transition in progress in unstable

[Theodore Ts'o]

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> 
> Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> either the existing non-t64 library will be kept installed because nothing
> yet needs the t64 version, or something does want the t64 version and apt
> will accept it as a replacement for the non-t64 version because it Provides:
> the non-t64 name.
> 
> So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> NOT working, I think we should want to see some apt output showing what's
> not working.

Sorry, I've been crazy busy so I didn't have time to object to
libuuid1t64 as bewing compltely unnecessary before it had rolled out
to unstable.  Similarly, libcom-err2 and libss2 don't use time_t, so
the rename to ...t64 was completely unnecessary.

On my todo list was to figuire out how to revert them, but given that
libuuid1t64 has been causing problems and has required the revert, I
was planning on waiting for the dust to settle before trying to fix up
libcom-err2 and libss2.

(None of this is intended to be a criticism of the team working on
time_t transition; I understand how it's hard to figure out whether a
library has a time_t exported in their interface.  Unfortunately, I
had less than a week to respond, and it happened while I was
travelling, so I didn't have time to review before I saw the upload to
unstable, and I figured out that it was too late for me to object.)

 - Ted

Re: 64-bit time_t transition in progress in unstable

[Kevin Bowling]

On Wed, Mar 6, 2024 at 4:18 PM Russ Allbery  wrote:
>
> Eric Valette  writes:
>
> > You can force the migration by explicitly adding the package that it
> > propose to remove (e.g gdb for libelf, ...)
>
> > I managed to upgrade all packages you mention in your mail that
> > way. Only libkf5akonadisearch-bin libkf5akonadisearch-plugins
> > libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64
> > libkf5akonadisearchxapian5t64 are missing because there are bugs in the
> > Provides: for api /or the packe depending on the T64 ABI are not yet
> > rebuild. I opened a bug for that
>
> Ah, yes, that worked.  It took some experimentation to figure out which
> packages could be forced and which ones were causing removals.
>
> I'm down to only libzvbi-common having problems, which I can't manage to
> force without removing xine-ui.  If I attempt to install them both
> together, I get this failure:
>
> The following packages have unmet dependencies:
>  libxine2 : Depends: libxine2-plugins (= 1.2.13+hg20230710-2) but it is not 
> going to be installed or
>  libxine2-misc-plugins (= 1.2.13+hg20230710-2+b3) but it 
> is not going to be installed
>  libxine2-ffmpeg : Depends: libavcodec60 (>= 7:6.0)
>Depends: libavformat60 (>= 7:6.0)
>
> The apt resolver seems to be struggling pretty hard to make sense of the
> correct upgrade path.

As of this evening these are the packages that currently have broken
deps on amd64 for me:
gstreamer1.0-plugins-good gstreamer1.0-pulseaudio
libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc

>
> --
> Russ Allbery (r...@debian.org)  
>