Bug#1057377: ITP: slidge-matridge -- Feature-rich Matrix to XMPP puppeteering gateway
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package Name: slidge-matridge Version: 0.0.0-dev0 Upstream Author: Nicolas Cedilnik License: ALGPL-3 Programming Lang: Python 3 Homepage: https://git.sr.ht/~nicoco/matridge Description: Feature-rich Matrix to XMPP puppeteering gateway, based on slidge and nio.
Re: Signature strength of .dsc
Judit Foglszinger writes: > Hi, > >> > Dmitri, could you re-run the numbers with the debian-maintainer keyring? >> >> That is correct. I have updated the results now. >> The 2,455 no public key has now become 1,238 > > Another is the DN keyring. > Also I'd expect many keys to be found in older versions of the keyring > package/keyring repository > and on keyservers like keyserver.ubuntu.com Removing old keys is usually a bad idea -- could these be moved to a "archived" keyring instead? I assume having them in the "live" keyring is not possible if the presence of a key in that file is used to make authorization decisions. You want to be able to verify old signatures in 20+ years too, and then you need to be able to find the corresponding public key. Even finding a copy of my own old RSA1280 key 0xB565716F turned out to be tricky, I had to search for it just a couple of days ago and I couldn't find it on the keyservers I looked on. The key was used during 2002-2014 to sign a lot of software releases (and emails). Fortunately, I had a habbit of sticking it into AUTHORS field of some packages so I found it here: https://git.savannah.gnu.org/cgit/libidn.git/tree/AUTHORS?id=cd51d7cd4e83f8b5240517b63ba2adef721542c9 /Simon signature.asc Description: PGP signature
Bug#1057386: Subject: ITP: imsprog -- linux chip programmer for CH341a devices
Package: wnpp Severity: wishlist Owner: Mikhail Medvedev X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : imsprog Version : 1.1.2-12 Upstream Author : Mikhail Medvedev * URL : https://github.com/bigbigmdm/IMSProg * License : GPL-3 Programming Lang: C, C++, Bash Description : GUI Chip programmer for CH341a devices IMSProg - QT-based GUI application - I2C, MicroWire and SPI EEP‐ ROM/Flash chip programmer for CH341a devices. The IMSProm is a free I2C EEPROM programmer tool for CH341A device based on QhexEdit2 and modify SNANDer programmer. IMSProg consists of three executable modules: 1. IMSProg - the chip programmer itself. 2. IMSProg_editor - chip database editor. 3. IMSProg_database_update - online chip database update from the ex‐ ternal web-server. -- Mikhail Medvedev
Bug#1057389: ITP: haproxy-cmd -- command line utility to control backends of haproxy
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: haproxy-cmd Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/third-party/haproxy-cmd * License : Apache-2.0 Programming Lang: Python Description : command line utility to control backends of haproxy This package contains a helper to send commands through the haproxy socket, so it is possible to maintain servers part of a cluster by draining, enabling and stopping servers part of a backend. . This utility is, in fact, a wrapper around the haproxy admin socket, so it is easier to use, with bash-completion and so on.
Bug#1057406: ITP: htgolang-github-inetaf-tcpproxy -- Proxy TCP connections based on static rules, HTTP Host headers, and SNI server names
Package: wnpp Owner: Reinhard Tartler Severity: wishlist * Package name: golang-github-inetaf-tcpproxy Version : latest git Upstream Author : inet.af authors * URL or Web page : https://github.com/inetaf/tcpproxy/ * License : Apache 2.0 Description : Proxy TCP connections based on static rules, HTTP Host headers, and SNI server names Needed as a dependency of golang-gvisor bindings, which is required by podman 4.8
Bug#1057415: ITP: golang-github-ghjm-cmdline -- Command line parser with multiple configurations for the Go language
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Go Packaging Team * Package name: golang-github-ghjm-cmdline Version : 0.1.2 Upstream Contact: Graham Mainwaring * URL : https://github.com/ghjm/cmdline * License : Apache-2.0 Programming Lang: Golang Description : Command line parser with multiple configurations for the Go language This package provides a parsing and execution framework based on the idea that structs define accepted fields, receiver functions, and execution phases. It is more general than the common Go language command line parser. This is needed by receptor, a cli needed by awx. I plan to team-maintain it within pkg-go team. Jérémy
Re: Pause /usr-merge moves
Hi developers, On Fri, Dec 01, 2023 at 10:04:12PM +0100, Helmut Grohne wrote: > Before we go, let me express sincere thanks to so many people that > helped me track this down. In particular, the input of David > Kalnischkies, Guillem Jover and Julian Andres Klode was invaluable. I got more feedback mainly from David Kalnischkies and Enrico Zini this time. Thank you for wrapping your head around this! > Julian Andres Klode proposes adding a "barrier package" that we may call > usrmerge-support (or repurpose usr-is-merged). Affected Conflicts can be > moved to the barrier package and the conflicting package would then > express Pre-Depends on the barrier package. When the barrier's postinst > runs, any conflicting package definitely has been removed and due to > using Pre-Depends, the conflicting package definitely has not been > unpacked yet. David Kalnischkies made me aware that we need to treat unversioned Conflicts separately from versioned Conflicts here. With unversioned ones, we typically manage the provider of a virtual facility. The barrier package approach can be used here, but it requires each provider to have its own barrier package rather than one central barrier package. Also when changing providers of a facility, apt will usually remove one provider explicitly before installing another without the --set-selections dance that triggers the problematic behaviour. I have not seen any way of invoking apt yet that would cause the problematic behaviour, but that can be due to me not trying hard enough. For versioned conflicts (where the conflicted version generally is in bookworm and not in trixie), a single central barrier package might do, but we can also start with one and split it up later if providing multiple barriers from the same binary package initially. For instance, the files diverted by molly-guard would require a barrier package that also handles bfh-container and progress-linux-container on one side and systemd, finit, kexec-tools, runit and sysvinit on the other. Such grouping can significantly reduce the number of barrier packages for the versioned case without severely limiting the options to the solver. > Another option is duplicating affected files (e.g. using hard links) in > the data.tar and then restoring lost files during postinst. I note that in case of systemd (and finit and runit), all of the affected files are symbolic links, so we can pull this off without actually changing data.tar and just restoring the links in postinst. We wouldn't actually need that many backup copies. I'll look into drafting a patch. > Depending on what problem we are solving, we may also move to protective > diversions (DEP17 M8). If we have a choice between introducing a barrier package and protective diversions, I think the protective diversions are the lesser evil. A big chunk of the not-yet-conflicts can probably be done with protective diversions instead. The thing that cannot be solved with protective diversions is diverting an aliased location. We cannot fix diversions with diversions unfortunately. Still that would lower the number significantly. It also is a little unclear how much effort we want to spend on avoiding this kind of breakage. When using apt, we want things to work, but when using dpkg directly and issuing dpkg --set-selections maybe that's used rarely enough that we can point out the problems in release notes and call it a day? In order to have apt not trigger this scenario, it seems sufficient if molly-guard from sid were usable with (aliased) systemd-sysv from bookworm (i.e. not having Breaks for bookworm's systemd-sysv). Doing that allows apt to simply upgrade molly-guard before systemd-sysv and then things would just work. You could still reproduce the file loss if you poked hard enough, but we could call those artificial cases than and ask people to reinstall affected packages after having experienced the file loss. How do others feel about reducing our support promise here? The total number of cases is also still very much vague. Reasons: * Unversioned conflicts incur a barrier package per provider while versioned conflicts can be grouped. The grouping can be changed if we use virtual barrier packages. * We do not know in advance how many affected packages are restructured and when they are, we may choose to mitigate those cases with protective diversions rather than Conflicts. I understand that this doesn't really answer Bastien's questions, but I don't have better answers. At this time I'm looking more feedback as to what our preferred trade-off is and reaching consensus about that question. The list of issues (including trixie ones) was already attached though. Helmut
Re: Pause /usr-merge moves
On Mon, Dec 04, 2023 at 01:13:43PM +0100, Helmut Grohne wrote: > David Kalnischkies made me aware […] Oh, did he? I think he wanted to tell you something else… 😉 As IRC seems to be really bad at transporting complicated things (who had guessed?) and I need to sort my thoughts anyhow let me recount the last few days in a lengthy mail… perhaps that helps me and whoever else might be interested. Disclaimer: /me is an independent APT developer for ~14 years aka super biased if the topic is upgrades and APT. Content warning: Gory details of APT and dpkg internals are described in text. Reader discretion advised. First of, I care only about APT (= meaning everything using libapt, be it apt, aptitude, unattended-upgrades or some python-apt script), not about someone who believes they could perform an upgrade from bookworm to trixie by hand with dpkg¹. I mean, APT can calculated it, so there obviously is a way, but its so tedious for a human being that nobody does that. Sure, there are people who believe "dpkg -i *.deb" would work, but a) that wouldn't be affected by this problem to begin with and b) it doesn't work as you have to spell out pre-depends, the order in which the debs are given is important and last but not least you have to work around a few things in dpkg (e.g. #832972, #844300). So whoever believes they can do it without APT are probably lying to themselves or at the very least wasting a lot of time such experts could use far better to improve APT and/or dpkg for the benefit of all… Source: I stumbled over many bugs while trying to simplify APT down to that dpkg call more than seven years ago, so that is not even a new thing and so not even worthy of grabbing your pitchforks because I supposedly impose new things you haven't adapted to yet… The release notes are actually saying you have to use 'apt', so I am affording a significant amount of leeway here talking about APT. (bootstrapping and such stuff which gets away with not using APT isn't upgrading anything, so this problem with Conflicts is of no concern) So, after clearing that one up, lets focus on the issue at hand: APT tells dpkg about all removes it will eventually schedule ahead of time so technically all (well… some?) Conflicts your yaml includes could be made to exhibit the problem, but APT usually always makes the removal of a package explicit as well and in that case you/we/usr-merge is fine. There is one exception we have to talk about: If a package is scheduled to be removed in one dpkg call and in the next one unpacked. I figured out today that I implemented that sorta by accident… actually, I was working on crossgrades (= a package changing architecture in an upgrade, which contrary to common usage of the word is at least for APT also the case for all <-> any and as such can happen even on a single architecture system) and accidentally its also catching temporary removals which don't change architecture, but are also removing a package before unpacking it (Its Debians fault for trusting me with this stuff…). While the former might be interesting to look at as another source of esoteric problems, lets focus on the temporary removals here: Unversioned conflicts [usually] do not cause temporary removal. They cause "permanent" removal as the packages aren't co-installable (yes, I mentioned you could conflict on a provides from bookworm which is removed in trixie. I don't think that actually happens in reality). A versioned conflict is discouraged by policy and by lintian. Okay, we need it here, so: It can cause it, but only if the conflict is mutual but the packages still co-installable on trixie AND they were also co-installable in bookworm (and for it to actually happen, they have to be installed both from bookworm on the user system of course). If "pkga conflicts pkgb (<< 2)" and "pkgb depends pkga (>= 2)" (like in a package rename perhaps) APT can just "unpack pkgb pkga" and all is fine. The problem you came with was instead "pkga conflicts pkgb (<< 2)" and "pkgb conflicts pkga (<< 2)" (its the same if ONE of them is a breaks, but not if both are) as APT can't just unpack them it has to remove one of them before unpack both. That is what I called a temporary removal as the package is only removed for a very short time. But that short amount of time is already too long if the packages involved are essential, which I suppose is the reason for §6.6 as if APT (as it currently does by happy accident as described above) just tells dpkg that it is allowed to deinstall one of them and unpacks both dpkg can do its §6.6 dance to avoid the actual removal from disk. Yeah! I implemented a generic improvement by accident instead of a bug! Sadly, for usr-merge we need the removals to happen explicitly as dpkg can't untangle the aliasing. The barrier idea achieves this by the way of pre-depends as APT has to spell out pre-depends for dpkg aka it has to configure the barrier package before it can unpack t
Bug#1057435: ITP: golang-github-containers-gvisor-tap-vsocks -- golang bindings for gvisor
Package: wnpp Severity: wishlist Owner: Reinhard Tartler X-Debbugs-Cc: debian-devel@lists.debian.org, siret...@tauware.de * Package name: golang-github-containers-gvisor-tap-vsocks Version : 0.7.1 Upstream Contact: gvisor-tap-vsocks authors * URL : https://github.com/containers/gvisor-tap-vsoc * License : Apache-2.03 Programming Lang: Golang Description : golang bindings for gvisor this is a new dependencies for podman 4.8
Migration blocked
Hi all, I uploaded src:node-proxy-agents into unstable, which is the new source of node-proxy and node-https-proxy-agent. This package didn't migrate but I don't understand the reason of this block. The tracker[1] reports regressions on node-proxy and node-https-proxy-agent (which are replaced), and related logs contains "ERROR: erroneous package: rules extract failed with exit code 1". How can I fix this problem ? Best regards, Yadd [1]: https://tracker.debian.org/pkg/node-proxy-agents
