Re: /usr-merge status update + next steps
Control: forwarded -1 https://salsa.debian.org/debian/debhelper/-/merge_requests/108 Control: tags -1 + patch On Sun, Aug 20, 2023 at 11:19:56PM +0200, Michael Biebl wrote: > Related to that: > dh_installsystemd (and the old, deprecated dh_systemd_enable) currently only > consider systemd unit files that are installed to lib/ Thank you Michael and Niels (who privately pointed at the same thing). This is the kind of review that I was hoping for. > One could trick dh_installsystemd by running dh_usrmerge after > dh_installsystemd, but this approach obviously doesn't work, if you change > your package to build with --prefix=/usr, so the files are already in the > canonical location when dh_installsystemd runs. > > So this would need a corresponding change in dh_installsystemd. I guess for > the time being, it would make sense if the tool looked in both paths, at > least as long as the transition is ongoing. You are spot-on. Even before we released bookworm, we had a group of people (including Sebastian Ramacher and myself) advocating for doing this change. As far as I understand the discussion, the main argument against it was that it could encourage people to violate the moratorium. In reality, our refusal to fix this earlier did cause "reverse violations" of the moratorium where files previously shiped below /usr/lib in bullseye would be moved to /lib in bookworm. That happened to boinc-client, cfengine3, nvme-cli, podman, and powerman (see https://subdivi.de/~helmut/dumat.yaml). So I argue that the reasoning was wrong even back then. Keep in mind that Niels clarified that he wasn't really objecting the change, but didn't want to handle its fallout if any. Speaking of fallout, we now have DEP17 and dumat which allow as to quantitaively estimate what may break. * P1 is the main category we see here. This problem arises if we restructure packages and move files between / and /usr. Since we are rather early in the release cycle, not much restructuring has happened yet and all of the restructuring that would cause P1-style file loss, happened for bullseye->bookworm with nothing yet for bookworm->trixie (as of this writing). And since dumat.yaml is updated four times a day, we learn about such problems quickly. * P2 is a problem, but I've files patches for all in-archive instances already. No key packages are affected, so we can upgrade those bugs to RC-severity when problems arise. * P3 has had one instance that Luca Boccassi removed before bookworm, so for systemd units, no P3 problems are left in trixie and beyond. * P4/P5/P6/P7/P8/P9/P10 do not apply. If we were to lift the moratorium just for systemd units right now, we're likely to run into P1 problems due to later package restructuring, but there is little else that may go wrong. Due to these P1 problems, we still have the moratorium and I have repeatedly argued for an opt-in approach to moving files from / to /usr. Let me also put this into numbers. Across all suites, we have around 2200 binary packages shipping files in aliased locations. If you disregard systemd units, we're left with 1030 packages. In other words, more than half of the binary packages shipping files in aliased locations do so only via systemd units. I recognize that various people have repeatedly asked me to consider an opt-out approach and to look at these numbers. Thanks for your persistence. Does that also convince others to treat systemd units separate from the rest? It seems plausible to move systemd units in an opt-out fashion while moving other files in an opt-in fashion. The main benefit here is that we could use binNMUs to canonicalizes 1/3 of the archive. (This is less than half, because a number of packages shipping systemd units are Arch:all.) To me, the risks and cost savings for forcefully moving systemd units bear a trade-off that is worth considering (despite me earlier having argued otherwise). Unfortunately, evaluating risk is a subjective process to some extent and I know that we have quite some disagreement on how severe these risks are. How can we move forward here? In this instance, I welcome +1 and -1 style responses and you may send them directly to me if you want to save the list from such traffic. In any case, I implemented the changes to debhelper to recognize units in /usr. The change does not yet move units to /usr (as that is still prohibited by the moratorium and I don't think we have consensus on that aspect just yet). I am willing to handle the fallout of this change and have implemented the dumat service to quickly diagnose such fallout. Nevertheless, I welcome reviews of the debhelper MR referenced above. Niels already replied to the MR. He'll not interact (review/merge/upload) with the MR and authorized me to do those things (provided I handle possible fallout). Thank you. Helmut
Re: Bug#1050005: ITP: pdftopng -- Convert PDF to PNG
On Fri, Aug 18, 2023 at 1:19 PM Marvin Renich wrote: > > * Elena Grandi [230818 05:27]: > > Package: wnpp > > Severity: wishlist > > Owner: Elena Grandi > > > > * Package name: pdftopng > > Description : Convert PDF to PNG > > > > A command line tool and python library to convert PDFs to PNGs, based on > > pdftoppm from poppler. uh ? % pdftoppm -h 2>&1| grep png -png : generate a PNG file > > This is a dependency of camelot-py (#1049944) and I intend to maintain > > it in the Python Team. > > Does pdftocairo from the poppler-utils package do what you need? If > not, would it make sense to submit patches to add pdftopng to the > poppler-utils package instead of creating a separate package for it? ...or at least document why pdftoppm is not suitable.
Bug#1050241: ITP: libei -- Emulated Input client library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debia...@lists.debian.org Owner: tjaal...@debian.org Control: block 1050237 by -1 Package Name: libei Version: 1.0.0 Upstream Author: Red Hat License: Expat Programming Lang: C Description: Emulated Input client library libei is a library for Emulated Input, primarily aimed at the Wayland stack. It provides three parts: - EI (Emulated Input) for the client side (libei) - EIS (Emulated Input Server) for the server side (libeis) - oeffis for D-Bus communication with the XDG RemoteDesktop portal Other Info -- This package will be maintained by the Debian X Strike Force team. Packaging is at https://salsa.debian.org/xorg-team/lib/libei This is a new required dependency for Mutter 45. I believe GNOME Remote Desktop and xdg-desktop-portal-gnome will also be using it soon. More background can be found at the project's website: https://gitlab.freedesktop.org/libinput/libei Thanks, Jeremy Bícha
Bug#1050308: ITP: golang-github-seancfoley-bintree -- Golang library Binary trees and tries
Package: wnpp Severity: wishlist Owner: M Hickford X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com * Package name: golang-github-seancfoley-bintree * URL : https://github.com/seancfoley/bintree * License : Apache2 Programming Lang: Go Description : Golang library Binary trees and tries Transitive dependency for kitty
Bug#1050314: ITP: golang-github-sigstore-rekor -- Software Supply Chain Transparency Log
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-sigstore-rekor Version : 1.2.2-1 Upstream Author : sigstore * URL : https://github.com/sigstore/rekor * License : Apache-2.0 Programming Lang: Go Description : Software Supply Chain Transparency Log Rekor's goals are to provide an immutable tamper resistant ledger of metadata generated within a software projects supply chain. Rekor will enable software maintainers and build systems to record signed metadata to an immutable record. Other parties can then query said metadata to enable them to make informed decisions on trust and non-repudiation of an object's lifecycle. . The Rekor project provides a restful API based server for validation and a transparency log for storage. A CLI application is available to make and verify entries, query the transparency log for inclusion proof, integrity verification of the transparency log or retrieval of entries by either public key or artifact. . Rekor fulfils the signature transparency role of sigstore's software signing infrastructure. However, Rekor can be run on its own and is designed to be extensible to working with different manifest schemas and PKI tooling. This package will be maintained under the pkg-golang community's umbrella. It is going to be used by container management tools that are linked into podman
Re: Bug#1050005: ITP: pdftopng -- Convert PDF to PNG
On Tue, Aug 22, 2023 at 01:24:42PM +0200, Mathieu Malaterre wrote: > On Fri, Aug 18, 2023 at 1:19 PM Marvin Renich wrote: > > > > * Elena Grandi [230818 05:27]: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Elena Grandi > > > > > > * Package name: pdftopng > > > Description : Convert PDF to PNG > > > > > > A command line tool and python library to convert PDFs to PNGs, based on > > > pdftoppm from poppler. > > uh ? > > % pdftoppm -h 2>&1| grep png > -png : generate a PNG file > > > > This is a dependency of camelot-py (#1049944) and I intend to maintain > > > it in the Python Team. > > > > Does pdftocairo from the poppler-utils package do what you need? If > > not, would it make sense to submit patches to add pdftopng to the > > poppler-utils package instead of creating a separate package for it? > > ...or at least document why pdftoppm is not suitable. I would imagine, since the original ITP also mentioned a Python project that requires this package, that the "Python library" part may be important: the upstream authors of the other project may have decided to use it, as a Python library, instead of fiddling with child process management by themselves. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
