Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

On 21/09/25 23:05, Jonas Smedegaard wrote: Please do not do that. When you know(!) that dependencies are not satisfied but are at the risk of month-long NEW queue processing, upload to experimental instead of to unstable. I started doing that an hour ago with matrix-pickle{-derive,}. I don't

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

Quoting Philipp Kern (2025-09-21 23:20:46) > On 9/21/25 11:05 PM, Jonas Smedegaard wrote: > > Quoting NoisyCoil (2025-09-21 22:26:04) > >> On 21/09/25 10:41, Jonas Smedegaard wrote: > >> > Please do not knowingly destabilize Debian unstable, but release known > >> > broken packages to experimen

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

Quoting NoisyCoil (2025-09-21 22:26:04) > On 21/09/25 10:41, Jonas Smedegaard wrote: > > Please do not knowingly destabilize Debian unstable, but release known > > broken packages to experimental, re-releasing to unstable only when > > dependencies are all there. > [...] there's no such thing a

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

man conversations. > >> > > This is not fair, and you know it. Many teams use an alioth mail as > > Maintainer: and their -lists mail for discussions. It's not uncommon > > that contributors in teams are not subscribed to the former. > > Not only it

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

On 9/21/25 11:05 PM, Jonas Smedegaard wrote: Quoting NoisyCoil (2025-09-21 22:26:04) On 21/09/25 10:41, Jonas Smedegaard wrote: > Please do not knowingly destabilize Debian unstable, but release known > broken packages to experimental, re-releasing to unstable only when > dependencies are

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

il as Maintainer: and their -lists mail for discussions. It's not uncommon that contributors in teams are not subscribed to the former. Not only it's not fair, it's also not true: bug reports -- featuring actual human conversations -- are sent to that email address. Best.

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

Hi Jonas, dropping bug report as my answer has nothing to do with it On 21/09/25 10:41, Jonas Smedegaard wrote: > Package: librust-tower-lsp-dev > Version: 0.20.0-1 > Severity: grave > X-Debbugs-Cc:debian-devel@lists.debian.org,debian-r...@lists.debian.org > > Package librus

Re: Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

On Sun, 21 Sep 2025 10:41, Jonas Smedegaard wrote: Package: librust-tower-lsp-dev Version: 0.20.0-1 Severity: grave X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package librust-tower-lsp-dev is impossible to install:

Re: Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

> > And to spell it out explicitly we would prefer if you changed from > A) > Upload $package + its missing dependencies to unstable > > (Causing unstable containing broken packages for $random, posibly very > very long time)) > > to > > B) > * Upload $package + its missing dependen

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On 21/09/25 15:35, Jonas Smedegaard wrote: I am not part of the Rust team. I am part of Debian. I am raining an issue generally in Debian, about a seemingly team-wide behaviour that I find inappropriate for Debian. I did not initially talk about build flags, but if others want to mix that into

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On 21/09/25 00:51, Jonas Smedegaard wrote: Quoting NoisyCoil (2025-09-20 21:16:08) On 20/09/25 18:37, Jonas Smedegaard wrote: What is sensible to me is to enable optimization by default and support DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers when a package apply some

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting NoisyCoil (2025-09-21 15:05:09) > On 21/09/25 00:51, Jonas Smedegaard wrote: > > Quoting NoisyCoil (2025-09-20 21:16:08) > >> On 20/09/25 18:37, Jonas Smedegaard wrote: > >>> What is sensible to me is to enable optimization by default and support > >>> DEB_BUILD_OTIONS=noopt. Then it is cle

Re: Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On Sun, Sep 21, 2025 at 6:23 AM Alexander Kjäll wrote: > > > > And to spell it out explicitly we would prefer if you changed from > > A) > > Upload $package + its missing dependencies to unstable > > > > (Causing unstable containing broken packages for $random, posibly very > > very long

Re: Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting Alexander Kjäll (2025-09-21 12:23:01) > > > > And to spell it out explicitly we would prefer if you changed from > > A) > > Upload $package + its missing dependencies to unstable > > > > (Causing unstable containing broken packages for $random, posibly very > > very long time)) > >

Bug#1115885: librust-tower-lsp-dev: impossible to install: depends on missing librust-async-codec-lite-0.0+default-dev

Package: librust-tower-lsp-dev Version: 0.20.0-1 Severity: grave X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package librust-tower-lsp-dev is impossible to install: depends on missing package librust-async-codec-lite-0.

Re: Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On 2025-09-20 Jonas Smedegaard wrote: > Quoting Alexander Kjäll (2025-09-20 19:45:07) >>> It helps me (and Debian generally, I assume) that packages do not have >>> missing dependencies or build-dependencies when introduced to unstable, >>> and it is my understanding that when NEW queue is involve

Bug#1115472: ITP: mousam -- GUI appliction for Weather

Package: wnpp Severity: wishlist Owner: Seyed Mohamad Amin Modaresi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : mousam * Version : 1.4.0-1 * URL : https://github.com/amit9838/mousam * License : GPL-3+ Description : GUI appliction for Weather mousam -- GUI appliction for Weather

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

Hello Bjørn, As much as I and probably others agree that the networkd update and the communication on the bug are problematic, your way of communicating is not acceptable on any Debian list. The volume of your mails fails on the code of conduct item 4 ("try to be concise"). On Tue, Se

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting NoisyCoil (2025-09-20 21:16:08) > On 20/09/25 18:37, Jonas Smedegaard wrote: > > What is sensible to me is to enable optimization by default and support > > DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers > > when a package apply some tradeoff. > > We're talking abo

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

now this, given that we regularly file a large number of bug reports to your packages for this exact purpose. As for *this* specific "reorganization" (transition), it is only being discussed because I determined that the best way to fix zerovec, that as I said has been broken in

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On 20/09/25 18:37, Jonas Smedegaard wrote: What is sensible to me is to enable optimization by default and support DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers when a package apply some tradeoff. We're talking about policy, so we don't really care about non-default D

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting Alexander Kjäll (2025-09-20 19:45:07) > > It helps me (and Debian generally, I assume) that packages do not have > > missing dependencies or build-dependencies when introduced to unstable, > > and it is my understanding that when NEW queue is involved there is no > > way to know if they are

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

> It helps me (and Debian generally, I assume) that packages do not have > missing dependencies or build-dependencies when introduced to unstable, > and it is my understanding that when NEW queue is involved there is no > way to know if they are missing or not because that would requre a > crystal

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On 20/09/25 18:14, Fabian Grünbichler wrote: no, I am open to suggestions here. for example, running the dh_auto_test `cargo build/test` and/or the default features autopkgtest with a custom profile (basically dev/test + optimizations) might be a sensible compromise? that should catch most optimi

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting Fabian Grünbichler (2025-09-20 18:14:39) > On Sat, Sep 20, 2025, at 5:59 PM, Jonas Smedegaard wrote: > > Quoting Fabian Grünbichler (2025-09-20 17:31:44) > >> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote: > >> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote: > >> >> Quoting

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On Sat, Sep 20, 2025, at 5:59 PM, Jonas Smedegaard wrote: > Quoting Fabian Grünbichler (2025-09-20 17:31:44) >> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote: >> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote: >> >> Quoting Alexander Kjäll (2025-09-20 16:08:26) >> >> > And regardin

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote: > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote: >> Quoting Alexander Kjäll (2025-09-20 16:08:26) >> > And regarding running tests in debug, debug have additional checks for >> > numeric over-/underflows, something that easily happens w

Re: Bug#1115728: ITP: python3-pyglm -- PyGLM - OpenGL Mathematics (GLM) library for Python

Hi Timo, On Fri, 2025-09-19 at 17:17 +0200, Timo Röhling wrote: > Hi Sven, > > * Sven Geuer [2025-09-19 16:41]: > > * Package name    : python3-pyglm > >   Version : 2.8.2 > See https://bugs.debian.org/1114819 and > https://ftp-master.debian.org/new/python-pyglm_2.8.2-1.html Thanks for

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

, 2025, 15:48 NoisyCoil wrote: > Dropping cc on bug report and replacing pkg-rust-maintainers with > debian-rust, as these are policy discussions. > > On 20/09/25 10:31, Jonas Smedegaard wrote: > > My question is aimed at something else: Why did this happen in the first > >

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting Alexander Kjäll (2025-09-20 16:55:12) > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote: > > > Quoting Alexander Kjäll (2025-09-20 16:08:26) > > > Two quick thoughts from my mobile: > > > > > > Since transitioning through NEW takes so long, I typically upload as much > > > of the depen

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting Fabian Grünbichler (2025-09-20 17:31:44) > On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote: > > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote: > >> Quoting Alexander Kjäll (2025-09-20 16:08:26) > >> > And regarding running tests in debug, debug have additional checks for > >>

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Dropping cc on bug report and replacing pkg-rust-maintainers with debian-rust, as these are policy discussions. On 20/09/25 10:31, Jonas Smedegaard wrote: My question is aimed at something else: Why did this happen in the first place? I ask with this case as a concrete example, but I have

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard wrote: > Quoting Alexander Kjäll (2025-09-20 16:08:26) > > Two quick thoughts from my mobile: > > > > Since transitioning through NEW takes so long, I typically upload as much > > of the dependency tree as possible. But NEW is not a FIFO, so sometimes

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

Quoting Alexander Kjäll (2025-09-20 16:08:26) > Two quick thoughts from my mobile: > > Since transitioning through NEW takes so long, I typically upload as much > of the dependency tree as possible. But NEW is not a FIFO, so sometimes > thing pop out that is not buildable. A similar problem happen

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

On 20/09/25 16:08, Alexander Kjäll wrote: Since transitioning through NEW takes so long, I typically upload as much of the dependency tree as possible. But NEW is not a FIFO, so sometimes thing pop out that is not buildable. A similar problem happens if something is in NEW a long time and upgra

Bug#1115844: ITP: rust-io-keyring -- I/O-free keyring management

: https://github.com/soywod/io-keyring * License : Apache-2.0 or Expat Programming Lang: Rust Description : I/O-free keyring management I/O Keyring provides a set of I/O-free Rust coroutines and runtimes to manage keyring entries. This package is needed for himalaya (bug#1000161

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

e always prepare them in experimental if they involve packages > not maintained by the Rust Team. You must know this, given that we > regularly file a large number of bug reports to your packages for this > exact purpose. > > As for *this* specific "reorganization" (t

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P wrote: > > On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote: > > > I'm not aware of any current public activities to enable userspace > > > IBT. I haven't see any recent attempt to define a userspace/kernel ABI, > > > or to test (and port wh

Bug#1115728: ITP: python3-pyglm -- PyGLM - OpenGL Mathematics (GLM) library for Python

/alexhuntley/Plots [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060245 -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 signature.asc Description: This is a digitally signed message part

Bug#1115742: ITP: python-mcp -- Python SDK for Model Context Protocol

Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-mcp Version : 1.14.1 Upstream Contact: Anthropic, PBC * URL : https://github.com/modelcontextp

Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

staged in git) > - sourmash (needs patch) > > However, it seems the original packager (Sylvestre, apparently, in c.c.) > didn't package > > - autopkgtest dependencies of rust-lz4-flex > - yoke-derive, a dependency of yoke, which is a dependency of zerovec > (Bug#1073

Re: Bug#1115728: ITP: python3-pyglm -- PyGLM - OpenGL Mathematics (GLM) library for Python

Hi Sven, * Sven Geuer [2025-09-19 16:41]: * Package name    : python3-pyglm   Version : 2.8.2 See https://bugs.debian.org/1114819 and https://ftp-master.debian.org/new/python-pyglm_2.8.2-1.html Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁

Bug#1115708: ITP: pytest-asdf-plugin -- pytest plugin for testing ASDF schemas

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, debian-as...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-asdf-plugin Version : 0.1.1 Upstream Author : Brett Graham * URL : https://gith

Bug#1115683: ITP: viz1090 -- visualizer for dump1090 ADS-B data

Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: viz1090 Version : 0+git20250919+ds Upstream Authors: Nathan Matsuda URL : https://github.com/nmatsuda/viz1090 * License : BSD-2-clause Descripti

Bug#1115649: ITP: fusion -- sensor fusion library for IMUs

Package: wnpp Severity: wishlist Owner: Ahmad Khalifa X-Debbugs-CC: debian-devel@lists.debian.org * Package name: fusion Version : 1.2.8 Upstream Author : x-io Technologies * URL : https://github.com/xioTechnologies/Fusion * License : Expat Programming Lang:

Bug#1115648: ITP: rpcs3 -- PlayStation 3 emulator and debugger

Package: wnpp Severity: wishlist Owner: Ahmad Khalifa X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rpcs3 Version : 0.0.37+git20250916.335ed8d+ds-1 Upstream Author : rpcs3 authors * URL : https://github.com/RPCS3/rpcs3/ * License : GPL-2 Program

Bug#1115608: ITP: ktactilefeedback -- Tactile feedback library for Qt

Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ktactilefeedback Version : 1.0.0~git20250725.da7858a Upstream Contact: Jonah Brüchert (https://invent.kde.org/jbbgameich) * URL : https://invent.kde.org/jbb

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

* Emanuele Rocca: > Hi, > > On 2025-09-06 06:50, Guillem Jover wrote: >> Someone would need to check which shared objects are still not marked, >> in a similar way as what Emanuele Rocca has been doing for arm64 (with >> its PAC and BTI counterparts). > > On arm64, ELF files supporting what in Deb

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

Hi! On Tue, 2025-09-16 at 10:20:43 -0700, H.J. Lu wrote: > On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P wrote: > > On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote: > > > > I'm not aware of any current public activities to enable userspace > > > > IBT. I haven't see any recent attempt

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote: > > I'm not aware of any current public activities to enable userspace > > IBT.  I haven't see any recent attempt to define a userspace/kernel ABI, > > or to test (and port where necessary) userspace. > > Thanks. So, do any of you (Florian, R

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

On Tue, Sep 16, 2025 at 10:41:50AM +0200, Emanuele Rocca wrote: > On arm64, ELF files supporting what in Debian we call the "branch" > hardening features (PAC, BTI, GCS) are marked with a special ELF note. > > $ readelf -n a.out | grep Properties > Properties: AArch64 feature: BTI, PAC, GCS

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

Hi, On 2025-09-06 06:50, Guillem Jover wrote: > Someone would need to check which shared objects are still not marked, > in a similar way as what Emanuele Rocca has been doing for arm64 (with > its PAC and BTI counterparts). On arm64, ELF files supporting what in Debian we call the "branch" harde

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

Hi! [ For context, in Debian we have been building userland on amd64/x86_64 with -fcf-protection, where there does not seem to be userland support for IBT at all from the Linux kernel side. So we were wondering whether it makes sense to keep doing that or not. See start of thread at

Bug#1115349: ITP: golang-github-psanford-memfs -- In-memory implementation of Go's io/fs.FS interface

Package: wnpp Severity: wishlist Owner: Dr. Tobias Quathamer X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-psanford-memfs Version : 0.0~git20241019.4ef9117-1 Upstream Author : Peter Sanford * URL : https://github

Bug#1115260: ITP: fonts-atkinson-hyperlegible-next -- New (2024) second version of the Atkinson Hyperlegible fonts

Package: wnpp Severity: wishlist Owner: "Dr. Tobias Quathamer" X-Debbugs-Cc: debian-devel@lists.debian.org, to...@debian.org * Package name: fonts-atkinson-hyperlegible-next Version : 0.0~git20250221.7925f50 Upstream Contact: https://github.com/googlefonts/atkinson-hyperlegible-n

Bug#1115258: ITP: golang-github-ysmood-gson -- A tiny JSON lib to read and alter a JSON value.

Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-github-ysmood-gson Version : 0.7.3-1 Upstream Author : Yad Smood * URL : https://github.com/ysmood/gson * License : Expat Programming Lang: Go Description : Read and alter JSON

Bug#1115254: ITP: neovim-telescope-fzf-native -- fzf fuzzy finder backend for Telescope

Package: wnpp Severity: wishlist Owner: Carl Keinath X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: neovim-telescope-fzf-native Version : 0~git20250312 (snapshot) Upstream Contact: nvim-telescope team * URL : https://github.com/nvim-telescope/telescope-fzf

Bug#1115235: ITP: i2cexplorer -- i2c GUI utility

Package: wnpp Severity: wishlist Owner: Alexander Fomin X-Debbugs-Cc: debian-devel@lists.debian.org, fomin_a...@yahoo.com * Package name: i2cexplorer Version : 1.0.2 Upstream Contact: Alexander Fomin * URL : https://salsa.debian.org/AlexFomin/i2cexplorer * License

Bug#1115236: ITP: ssh-studio -- Easy, GUI SSH config editor and validator built with Python, GTK 4 and libadwaita

Package: wnpp Severity: wishlist Owner: Seyed Mohamad Amin Modaresi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : ssh-studio * Version : 1.2.1-1 * URL : https://github.com/BuddySirJava/SSH-Studio * License : GPL-3+ Description : Easy, GUI SSH config editor and validator built with

Bug#1115224: ITP: neovim-autopairs -- Autopair plugin for Neovim

Package: wnpp Severity: wishlist Owner: Carl Keinath X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: neovim-autopairs Version : 0~git20250701 Upstream Contact: windwp * URL : https://github.com/windwp/nvim-autopairs * License : MIT Programming La

Bug#1115184: ITP: golang-github-kshedden-statmodel -- Statistical modeling in Go

Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: golang-github-kshedden-statmodel Version : 0.0~git20210519.ee97d3e-1 Upstream Author : Kerby Shedden * URL : https://github.com/kshedden/statmodel * License : BSD-3-clause Programming Lang:

Bug#1115182: ITP: golang-github-kshedden-dstream -- Process data streams in Golang

Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: golang-github-kshedden-dstream Version : 0.0~git20190512.c4c4106-1 Upstream Author : Kerby Shedden * URL : https://github.com/kshedden/dstream * License : BSD-3-clause Programming Lang: Go

Bug#1115179: ITP: lsp-tree-sitter -- Python library to create language servers

Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lsp-tree-sitter Version : 0.0.18 Upstream Author : Wu Zhenyu * URL : https://github.com/neomutt/lsp-tree-sitter/ * License : GPL-3 Progra

Bug#1115173: ITP: sphinxcontrib-autofile -- Extension to generate module information from a glob expression

Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-autofile Version : 0.0.2 Upstream Author : Wu Zhenyu * URL : https://github.com/sphinx-contrib/autofi

Action on old unreproducible bug

Hi, I am the maintainer of mini-httpd. I have a vintage (2009) bug:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516309 I can't replicate it in latest version at all, but no patch specifically fixed the bug. It is possible the source shifted so much in the last 16 years that something fix

Re: Action on old unreproducible bug

gt; to > > reproduce (unlikely) ? It happened in a very niche situation > > anyway. > > I would close such bug, with the closing message being an invitation > to > re-open it if anyone happens to reproduce it. To make it clear it’s > not > closed as "won

Re: Action on old unreproducible bug

way. > I would close such bug, with the closing message being an invitation to > re-open it if anyone happens to reproduce it. To make it clear it’s not > closed as "won’t fix", but more as "can’t reproduce". I tend to tag this kind of bug report as "unreproduc

Re: Action on old unreproducible bug

Le Sat, Sep 13, 2025 at 01:31:49PM +0300, Alexandru Mihail a écrit : > This is more of a philosophical question. Do I close or keep trying to > reproduce (unlikely) ? It happened in a very niche situation anyway. I would close such bug, with the closing message being an invitation to re-o

Bug#1115080: No sound on HDMI (other outputs work) on Testing (forky/sid))

In addition, compared to my other 8. gen laptop, it HDMI is plugged in, i get more HDMI output devices in pavucontrol. On this device with the problem, there is only the internal source, and no additional HDMI outputs. So the problem will be that something is not recognizing the output devices, or

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

On Tue, 2025-09-09 at 10:52 +0200, Marc Haber wrote: > On Tue, Sep 09, 2025 at 09:24:38AM +0100, Adam D. Barratt wrote: > > That's exactly the sort of scenario that stable-updates exists for. > > It's enabled by default by d-i, and to the best of my recollection > > has > > been since it was introd

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

On Tue, Sep 09, 2025 at 09:24:38AM +0100, Adam D. Barratt wrote: That's exactly the sort of scenario that stable-updates exists for. It's enabled by default by d-i, and to the best of my recollection has been since it was introduced in squeeze. It's explicitly listed as an expected part of an APT

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

by bluca are still hurting Debian users. Apparently blucas feelings was so hurt by the this bug report that he had to take a few days off, while more and more Debian stable systems go offline around the world. I propose that Debian drops bullet point 4 from the social contract. It looks like a

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

On Tue, 2025-09-09 at 09:51 +0200, Marc Haber wrote: > The actual problem that we are facing that there is no possibility of > undoing the point release short of doing another quick followup 13.2 > or 13.1.1 point release to fix this. The broken systemd is in > _stable_ with the old version gone,

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

Debian users. Apparently blucas feelings was so hurt by the this bug report that he had to take a few days off, while more and more Debian stable systems go offline around the world. I propose that Debian drops bullet point 4 from the social contract. It looks like a bad joke at the moment. Or

Re: Bug#1112535: /usr/lib/systemd/systemd-networkd: segfault after upgrade to 257.8-1~deb13u1, no connectivity after reboot

pparently blucas feelings was so hurt by the this bug report that he had to take a few days off, while more and more Debian stable systems go offline around the world. I propose that Debian drops bullet point 4 from the social contract. It looks like a bad joke at the moment. Or maybe there is one DD

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

ixed in > > experimental as "closed" in the BTS and I invite you to answer the > > following simple question: Where in earth is stated that version > > tracking *mandates* such thing? > > The default behavior of our archive is that if you add a "Closes:

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

38 +0200, Santiago Vila wrote: > > > > Closing FTBFS bugs when they are only fixed in experimental is > > > > misleading. > > > > > > No, it's not. The BTS has version tracker for ages (even in Debian time > > > scales). > > > > Y

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

BTS has version tracker for ages (even in Debian time > > > > scales). > > > > > > Yes, it is misleading for anybody looking at the web page and seeing > > > the bug at the very end of the page and closed. Not everybody uses UDD > > > to get bug

Re: why package Signal in Debian? (was Re: Bug#1113746: ITP: node-noop6 -- No operation as a module using an arrow function)

On 2025-09-03 17:25 +0200, Sebastian Reichel wrote: There is an unofficial Flatpak that does build from source and provides arm64 binaries (which are not provided by Signal themself): https://github.com/signalflatpak/signal That is excellent news. Signal is useful, but also infuriating because

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

the following simple question: Where in earth is stated that version tracking *mandates* such thing? The default behavior of our archive is that if you add a "Closes: #bug" to your changelog, that the bug is closed. I consider that "documentation by code" and long stan

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

[ not cc:ing the bug anymore, moving to -devel ] Richard Lewis wrote: > Wouldnt that logic suggest that all bugs that also affect stable to be > left open until the next stable release? [...] No. When I say "still work to do" I mainly refer to FTBFS bugs, i.e those cases where a

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

* Guillem Jover: > But, if the current IBT approach seems undesirable, I'd still be open to > switch to -fcf-protection=return for now, and revisit how to handle IBT > later. CCing Florian for potentially more context and opinion. I'm not aware of any current public activities to enable userspace

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

Hi Santiago, On 07-09-2025 11:45, Richard Lewis wrote: Nothing gained? Visibility. You admit that the end user using the web interface still needs to open the bug in the browser to see the versions affected, and only then the end user would realize that there is *still* work to do. I have to

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

o Vila wrote: >> > > > Closing FTBFS bugs when they are only fixed in experimental is >> > > > misleading. >> > > >> > > No, it's not. The BTS has version tracker for ages (even in Debian time >> > > scales). >> > >

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

> > Version tracking was supposed to help people, not to make their work > > more painful or to force them to jump through hoops. > > Version tracking is helping here. The bug is still open in unstable and > forky. The BTS exactly tells you that. No, the bug is closed. T

Re: Bug#1113864: Replace -fcf-protection=full with -fcf-protection=return

Hi! I've now filed #1114518 against glibc to request enabling CET in permissive mode. I'll also prepare a change for the release notes, which incorrectly state we have full CET support in trixie. :/ On Wed, 2025-09-03 at 18:14:05 +0200, Marcos Del Sol Vives wrote: > El 03/09/2025 a las 17:47, Gui

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

> No, it's not. The BTS has version tracker for ages (even in Debian time > > scales). > > Yes, it is misleading for anybody looking at the web page and seeing > the bug at the very end of the page and closed. Not everybody uses UDD > to get bug information, there are still hum

Re: Bug#1114180: libplacebo: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v returned exit code 1

On 2025-09-06 16:49:50 +0200, Santiago Vila wrote: > > > Version tracking was supposed to help people, not to make their work > > > more painful or to force them to jump through hoops. > > > > Version tracking is helping here. The bug is still open in unstable and &g

Bug#1114034: ITP: golang-cel-expr -- Common Expression Language

Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-cel-expr Version : 0.24.0-1 Upstream Author : Google * URL : https://github.com/google/cel-spec * License : Apache-2.0 Programming Lang: Go Description : Common Expression Langu

Bug#1095077: I intend to package directxshadercompiler

Package: wnpp Followup-For: Bug #1095077 Owner: "antoine.lassa...@canonical.com" X-Debbugs-Cc: debian-devel@lists.debian.org I will package this one according to what lunarG did in their own self-hosted packaging.

Bug#1114035: ITP: golang-github-trustelem-zxcvbn -- Go implementation of Dropbox's zxcvbn realistic password strength estimator

Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-github-trustelem-zxcvbn Version : 1.0.1-1 Upstream Author : Vincent Vanackere and Trustelem * URL : https://github.com/trustelem/zxcvbn * License : Expat Programming Lang: Go Descri

Bug#1113986: ITP: nethsm-pkcs11 -- PKCS#11 module for Nitrokey NetHSM

Package: wnpp Severity: wishlist Owner: Tobias Deiminger X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org * Package name: nethsm-pkcs11 Version : 1.7.2 Upstream Contact: Technical support supp...@nitrokey.com * URL : https://github.com/Nitrokey

Bug#1113974: ITP: apt-suggest-auto -- Suggests and optionally marks manually installed packages as automatic

Package: wnpp Severity: wishlist Owner: Lucas Nussbaum X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: apt-suggest-auto Version : 0.1 Upstream Contact: Lucas Nussbaum * URL : https://salsa.debian.org/lucas/apt-suggest-auto * License : GPL-2.0-or-l

Bug#1113968: ITP: golang-github-savsgio-gotils -- Golang utlities to make your life easier with zero allocations

Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-github-savsgio-gotils Version : 0.0~git20250408.196191e-1 Upstream Author : Sergio VS * URL : https://github.com/savsgio/gotils * License : Apache-2.0 Programming Lang: Go Descripti

Bug#1113966: ITP: golang-github-fasthttp-router -- Router implementation for fasthttp

Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-github-fasthttp-router Version : 1.5.4-1 Upstream Author : FastHTTP solutions * URL : https://github.com/fasthttp/router * License : BSD-3-clause Programming Lang: Go Description

Bug#947407: I intend to package vulkancapsviewer

Package: wnpp Followup-For: Bug #947407 Owner: "antoine.lassa...@canonical.com" X-Debbugs-Cc: debian-devel@lists.debian.org As there is already an ITP about this package, I sent an email last week just in case. But given the ITP was sent in 2019 and there are no news since, I suppose

Bug#1113965: ITP: golang-authelia-provider-oauth2 -- Authelia OAuth 2.0 Framework (Provider Role)

Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-authelia-provider-oauth2 Version : 0.2.16-1 Upstream Author : Authelia * URL : https://github.com/authelia/oauth2-provider * License : Apache-2.0 Programming Lang: Go Description

Bug#1113964: ITP: gitkeeper -- Tracks specified git repos for sysadmins

Package: wnpp Severity: wishlist Owner: Keyu Tao X-Debbugs-Cc: debian-devel@lists.debian.org, m...@taoky.moe * Package name: gitkeeper Version : 0.20250903.0 Upstream Contact: Keyu Tao * URL : https://github.com/taoky/gitkeeper * License : MIT Programming La

Re: why package Signal in Debian? (was Re: Bug#1113746: ITP: node-noop6 -- No operation as a module using an arrow function)

> > I would encourage you to > start packaging signal-desktop and than we can find answers along the way. > A lot of discussion will get easier if signal-desktop is packaged, as than > everyone can look at the package; sneak into the code etc. > On one side you're completely right, on the other ha

Bug#1113922: ITP: neovim-everforest -- The Everforest colour scheme, ported to Lua for use with Neovim

Package: wnpp Severity: wishlist Owner: Paul Barker X-Debbugs-Cc: debian-devel@lists.debian.org, p...@pbarker.dev * Package name: neovim-everforest Version : 0~20250819 Upstream Contact: William Mathewson * URL : https://github.com/neanias/everforest-nvim * License

  1   2   3   4   5   6   7   8   9   10   >