Re: isa-support -- exit strategy?
On Wed, Apr 06, 2022 at 01:38:09PM +0200, Adam Borowski wrote: > On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote: > > On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote: > > > * while a hard Depends: works for leafy packages, on a library it > > > disallows having alternate implementations that don't need the > > > library in question. Eg, libvectorscan5 blocks a program that > > > uses it from just checking the regexes one by one. > > > glibc 2.33 added a modernized version of the old hwcaps. > > If a package builds a library several times with different optimizations > > and installs them into the correct directories in the binary package, > > the dynamic linker will automatically select the fastest one supported > > by the hardware. > > > > SIMDe (or similar approaches) could be used to build variant(s) of the > > library that have compile-time emulation of SIMD instructions in the > > lower baseline builds of vectorscan. > > In this particular case, it'd probably be faster to use non-SIMD ways > instead of emulating them. This means two code paths, which particular > users may or may not want to do the effort to implement. For supporting older baselines my priority would be functionality with minimal effort both for upstreams and Debian maintainers, not optimal performance on old hardware. > > For binaries, I have seen packages in the Debian Med (?) team that build > > several variants of a program and have a tiny wrapper program that chooses > > the correct one at startup. > > This may take substantial work to implement, which for typical Debian Med > packages is an utter waste of time. >... The proper approach would be to have the implenmentation in debhelper, so that the maintainer only has to declare which n different variants of the program to build on $architecture, and then everything including the wrapper is built by debhelper. I am not saying that I plan to implement it, but that's how I would design it to avoid the per-package work you are worried about. cu Adrian
Bug#1009713: RFP: netavark -- A container network stack
Package: wnpp Severity: wishlist * Package name: netavark Version : 1.0.2 Upstream Author : github.com/containers * URL or Web page : https://github.com/containers/netavark * License : MIT Description : A container network stack Podman 4.0 recommends this and its compainion package 'https://github.com/containers/aardvark-dns'. I'm not familiar with rust packaging, and would really appreciate if someone would give me a hand with updating required dependencies and packaging it properly.
Work-needing packages report for Apr 15, 2022
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1247 (new: 1) Total number of packages offered up for adoption: 179 (new: 1) Total number of packages requested help for: 63 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: rust-rustls (#1009375), orphaned 2 days ago Description: Modern TLS library Reverse Depends: librust-rustls+log-dev Installations reported by Popcon: 3 Bug Report URL: https://bugs.debian.org/1009375 1246 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: swagger-core (#1009673), offered today Description: Java implementation of the OpenAPI Specification Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/1009673 178 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1279 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (133 more omitted) Installations reported by Popcon: 98965 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 38 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core firejail (18 more omitted) Installations reported by Popcon: 187473 Bug Report URL: https://bugs.debian.org/1006872 aufs (#963191), requested 663 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 8692 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1961 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1235 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3854 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 657 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1829 days ago Description: Rust package manager Reverse Depends: dh-cargo rust-all Installations reported by Popcon: 2860 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 469 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 849 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 403 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 208534 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1161 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 407 Bug Report URL: https://bugs.debian.org/921717 debtags (#962579), requested 673 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1458 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 2099 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core Installations reported by Popcon: 43655 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2784 days ago Description: guidelines and information for Debian developers
Is there room for improvement in our collaboration model?
Hi, I just noted this problem recently. Our model for team collaboration (specifically for package maintenance) is somewhat primitive. We are volunteers. Nobody can continuously maintain a package for decades like a machine. Currently our practice for accepting other people's help involves: (1) low-threshold NMU. This is not quite easy to lookup (only shows on tracker.d.o, etc) (2) VAC note in debian-private channel. Who remembers you said the others can help you upload a package? And when does that temporary permission expire? What tracks that? (3) salsa permission. Yes, after joining the salsa team, others can commit code as they like. However, when it needs to be uploaded, the others still have to write mail to the maintainer for an ack. Whether multiple peoples should commit at the same time is coordinated through emails in order to avoid duplicated work. (4) last-minute NMU/delayed. When the others cannot bear an RC bug anymore, they may want to nmu upload to the delayed queue. (5) intend to salvage. When the others cannot hear from me for very long time, this is the only formal way to take over maintanence (afaik). The problems are: (1) whether multiple people should work on the same package at the same time is based on human communication. Namely, acquiring lock and releasing lock on a package is done through human communication. This is clearly something could be improved. It should be some program to acquire and release the lock. (2) different packages are clearly regarded differently by people. I'm actually very open to the other people hijacking some of my selected packages and fix these packages as they like. Namely, I think there should be a system where we can optionally tag our packages as: A. The other DDs can do whatever they like to this package and upload directly without asking me in a hijacking way. B. May git commit but should ask before upload. C. Must ask before any action. D. ... You know that in parallel programming, optimizing IPC (in this context it would be inter-DD communication) and optimizing the locking mechanism could help. My motivation for pointing these stems from some uncomfortable feelings when it's hard to get response from busy maintainers. If I understand correctly, technically DDs have enough permission to hijack any package and do the upload. People are polite and conservative to not abuse that power. But ... in order to improve contributor experience in terms of collaboration ... maybe we can use that tagging mechanism to formally allow a little bit of upload permission abuse. I think this will also improve newcomer's contributing experience. This proposal is also filed at https://salsa.debian.org/debian/grow-your-ideas/-/issues/34
Bug#1009715: ITP: golang-github-leonelquinteros-gotext -- Go (Golang) GNU gettext utilities package
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-github-leonelquinteros-gotext Version : 1.5.0-1 Upstream Author : Leonel Quinteros * URL : https://github.com/leonelquinteros/gotext * License : Expat Programming Lang: Go Description : Go (Golang) GNU gettext utilities package GNU gettext utilities (https://www.gnu.org/software/gettext) for Go. . Features . * Implements GNU gettext support in native Go. * Complete support for PO files (https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html) including: * Support for multiline strings and headers. * Support for variables inside translation strings using Go's fmt syntax (https://golang.org/pkg/fmt/). * Support for pluralization rules (https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html). * Support for message contexts (https://www.gnu.org/software/gettext/manual/html_node/Contexts.html). * Support for MO files. * Thread-safe: This package is safe for concurrent use across multiple goroutines. * It works with UTF-8 encoding as it's the default for Go language. * Unit tests available. * Language codes are automatically simplified from the form en_UK to en if the first isn't available. * Ready to use inside Go templates. * Objects are serializable to []byte to store them in cache. * Support for Go Modules. This is a dependency of git-lfs and will be maintained by the go packaging team.
