Work-needing packages report for Jun 11, 2021
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: 1225 (new: 0) Total number of packages offered up for adoption: 203 (new: 0) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 1225 packages are orphaned. See https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 203 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 971 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 (139 more omitted) Installations reported by Popcon: 94697 Bug Report URL: https://bugs.debian.org/910917 asciio (#968843), requested 292 days ago Description: dynamically create ASCII charts and graphs with GTK+2 Installations reported by Popcon: 74 Bug Report URL: https://bugs.debian.org/968843 aufs (#963191), requested 355 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 11924 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1653 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1215 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3546 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 621 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1521 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 2295 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 161 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: 1006 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 95 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: 201591 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 853 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: 427 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 2087 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd cyrus-murder (78 more omitted) Installations reported by Popcon: 201035 Bug Report URL: https://bugs.debian.org/799864 dbad (#947550), requested 530 days ago Description: dnsmasq-based ad-blocking using pixelserv Bug Report URL: https://bugs.debian.org/947550 debtags (#962579), requested 365 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1500 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 1791 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: 26122 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2476 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 4547 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 2081 days ago Description: scripts to make the life of a Deb
Re: What are desired semantics for /etc/shells?
Hi Helmut, Helmut Grohne, on 2021-06-10: > This raises the question of what the desired semantics for `/etc/shells` are. > Do we want the strict interpretation of the policy to be followed and update > all those packages to conditionalize their `add-shell` invocations? Or is > `/etc/shells` a simple collection of installed shells and administrators are > not supposed to mess with it? The latter interpretation somewhat conflicts > with > our policy, so we might have to update it. If `/etc/shells` is not to be > messed > with, maybe it should not live inside `/etc`? With my Debian User and system administrator hat on, I tend to find the behavior of having shells going back to /etc/shells after upgrade a bit surprising. I might find both effects on chsh(1) and on random services to be of interest, given the description of shells(5): >> /etc/shells is a text file which contains the full path‐ >> names of valid login shells. This file is consulted by >> chsh(1) and available to be queried by other programs. >> >> Be aware that there are programs which consult this file >> to find out if a user is a normal user; for example, FTP >> daemons traditionally disallow access to users with >> shells not included in this file. Perhaps I would have liked to reduce the choice of shells for regular users to a known subset for reasons; I can think of some distributed applications expecting a specific kind of user shell, in order to work properly, yet have further command interpreters for all sorts of needs. Thus, I'm very tempted to think bringing back a removed shell to /etc/shells, on a shell package upgrade, would be a genuine bug against said shell package. That being said, this is only my point of view, and I don't actually meddle much with /etc/shells, so don't really have a strong opinion on the topic. Still, I believe that it is reasonable to think there are installations somewhere which might rely on administrator maintained /etc/shells, so if it is due to become solely maintained by software, then it would be well worth a release note, I guess. In hope this is of interest for your work on improving packaging conditions and installation bootstrap, have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Bug#989699: ITP: ignition-tool -- ign command line tool that accepts multiple subcommands
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero * Package name: ignition-tools Version : 1.2.0 Upstream Author : Open Robotics * URL : http://ignitionrobotics.org/libraries/tools * License : Apache2 Programming Lang: Ruby Description : ign command line tool that accepts multiple subcommands Ignition tools provide the ign command line tool that accepts multiple subcommands. Each subcommand is implemented in a plugin that belongs to a specific Ignition project. For example, all the commands that start with ign topic ... will be implemented by the Ignition Transport library.
What are desired semantics for /etc/shells?
Hi, Due to working on installation bootstrap, I was looking into `/etc/shells`. Introduction `/etc/shells` contains valid login shells. Some programs match the configured shell of a user against this file to check whether a user is a normal user or a system users. For details on this file refer to `man 5 shells`. On Debian systems, it can be managed using the commands `add-shell` and `remove-shell` both of which are part of `debianutils`. Inconsistency = Some maintainer scripts take care to only run `add-shell` for initial configuration or for upgrading from an ancient version that didn't call `add-shell`. Others call `add-shell` for every invocation of `postinst`. Packages that only call `add-shell` once: * `bash` * `bash-static` * `dash` * `sash` * `tmux` Packages that only call `add-shell` during `postinst configure`: * `csh` * `elvish` * `mksh` * `screen` * `tcsh` Packages that call `add-shell` during any `postinst` invocation: * `9base` * `fish` * `ksh` * `myrescueshell` * `rc` * `xonsh` * `yash` * `zsh` * `zsh-static` In practice, all of the packages will add their shells on initial configuration. The second and third category will also add their shell on package upgrades. Arguably, doing so violates Debian policy section 10.7.3, which says that package upgrades must preserve local changes (such as removing a shell) on upgrades. Desired behaviour = This raises the question of what the desired semantics for `/etc/shells` are. Do we want the strict interpretation of the policy to be followed and update all those packages to conditionalize their `add-shell` invocations? Or is `/etc/shells` a simple collection of installed shells and administrators are not supposed to mess with it? The latter interpretation somewhat conflicts with our policy, so we might have to update it. If `/etc/shells` is not to be messed with, maybe it should not live inside `/etc`? Declarative packaging = Editing `/etc/shells` by running a command during a maintainer script is less than ideal when it comes to declarative packaging. The goal of declarative packaging is to make reasoning about packages easier by eliminating the need for maintainer scripts as much as possible. One solution for this case could be `dpkg-trigger`. All the shell-providing packages could drop a snippet into a particular directory and `debianutils` could concatenate them into `/etc/shells`. Doing so would delete quite a number of maintainer scripts and centralize the chance for introducing bugs and inconsistencies such as the ones above into one maintainer script. I think using triggers has an obvious benefit here, but depending in the intended semantics of `/etc/shells`, implementing the part about preserving user changes may be difficult. A possible solution could be moving `/etc/shells` to `/var` and replacing it with a symbolic link when its contents match with the generated one one. For the installation bootstrap, the trigger-based solution would make any ordering issues related to `/etc/shells` fully go away. That would be quite an improvement. Helmut
Re: Seeking feedback on a meta package builder
Hi Raphaël, On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote: > I want to know it precisely in the context of selecting a worker. I don't > want to schedule a task on a worker and later get back an answer "sorry I > can't handle your task", and then have to schedule it on some other > worker. I'm a little unsure what you mean precisely here. Do you want your scheduler call out to your worker and ask it whether it can handle the build? Or do you want to locally decide whether your worker can handle it (e.g. using data previously acquired from the worker and cached on the scheduler)? Or do you want to know whether a backend is capable of satisfying a request in principle without considering the concrete system performing the build? I guess it is not the last variant, because you cannot validate the distribution in any way. I guess it also is not the first variant, because you don't want to call into every single worker for every single build object. Do you confirm that you want the second variant? That might be a little more difficult due to the data collection part. I'm not sure I can reasonably cover that. > When I have selected a worker, I want to be sure that the worker > is properly configured to be able to run that specific task. That much makes sense in principle, but what do you want debusine to do when one of your workers is misconfigured and cannot reach its primary mirror? All builds there will fail and likely you can identify that the failure happened too early for the package to be at fault. You can either pass down the failure such that users have to deal with temporary issues or automatically reschedule the build elsewhere. Additionally, you can disable such a worker of course. Still, I suggest that you cannot rule out all possible worker-specific failure modes ahead of time. > Yes, but using the ssh backend will require specific user configuration > while the sbuild/pbuilder one could potientially be auto-selected based > on whether the user did run the appropriate sbuild-create-chroot or > pbuilder --create earlier. That definitely is implementable. It could be a simple "use sbuild if it works, else try pbuilder, else try mmdebstrap with a default mirror". I don't think I'd use it, but it might be a good default value for tools that need to perform builds. I've taken a note and will look into implementing this. > "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I > don't care how it gets built!). Indeed, one of my use cases is to get a log and no .debs. You can explicitly request no artifacts and that'll prevent them from being transferred over mdbp-ssh. > "deblord" or "debring" - the lord of the ring to tie all package builders > together Hmm. The more I think about this, the more I like the untypable mdbp: You only type it once to configure your application that does perform builds. If you actually type mdbp regularly, you're doing it wrong. It really is not meant as a frontend to be used interactively. Helmut
Re: Seeking feedback on a meta package builder
On Thu, Jun 10, 2021 at 8:01 AM Raphael Hertzog wrote: > > > > PS: I already hate the "mdbp" name after having it typed so many times. > > > > I'm not attached to either. Any suggestions? > > sbp for "standardized build package" is easier to type but not necessarily > nicer. > > "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I > don't care how it gets built!). > vendeb - vending machine for .deb > "deblord" or "debring" - the lord of the ring to tie all package builders > together > omegabuild - the last build system (also sort of a joke about being far from alpha software.) -m
Re: Seeking feedback on a meta package builder
Hi, On Tue, 08 Jun 2021, Helmut Grohne wrote: > With "look behind the abstraction", I think that you mean that debusine > would have to implement the mdbp api to perform worker selection. While > that would be possible indeed, I don't see this as required though. […] > I do wonder though, in what kind of situation would you want to merely > know whether a backend can perform a build as opposed to just attempting > it and being able to tell backend issues from actual build failures > apart. I want to know it precisely in the context of selecting a worker. I don't want to schedule a task on a worker and later get back an answer "sorry I can't handle your task", and then have to schedule it on some other worker. When I have selected a worker, I want to be sure that the worker is properly configured to be able to run that specific task. > > It would not be enough for debusine yet (for debusine I need to be able to > > export data from the worker and then make that decision on the server and > > not on the build machine itself) but it would be nice step forward for the > > local use case where you want "mdbp" to figure out alone which backend to > > use based on what the user did setup earlier. > > Yes, that makes sense. I note that the decision is meant to be made on > the build-issuing side for mdbp as well. If you use the ssh backend, the > relevant command might look like this: > > mdbp-ssh someserver.somesite mdbp-mmdebstrap --mirror > http://mirror.somesite/debian Yes, but using the ssh backend will require specific user configuration while the sbuild/pbuilder one could potientially be auto-selected based on whether the user did run the appropriate sbuild-create-chroot or pbuilder --create earlier. > > This abstraction definitely makes sense to me. Before looking closely > > at your build_schema.json, but after having looked at your mail here, > > I wrote this as a try to go in your direction: > > https://freexian-team.pages.debian.net/debusine/devel/ontology.html#task-packagebuild > > Great. Maybe that's the level where we can make best progress? Likely, yes. > I've taken the liberty to rather open a discussion issue at > https://salsa.debian.org/freexian-team/debusine/-/issues/10. Hope this > works for you. Yes, thanks! > > PS: I already hate the "mdbp" name after having it typed so many times. > > I'm not attached to either. Any suggestions? sbp for "standardized build package" is easier to type but not necessarily nicer. "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I don't care how it gets built!). "deblord" or "debring" - the lord of the ring to tie all package builders together Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#989677: ITP: golang-github-smallstep-truststore -- Package to locally install development certificates
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-smallstep-truststore Version : 0.9.6-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/truststore * License : Apache-2.0 Programming Lang: Go Description : Go library for locally installing development certificates This package is a dependency of caddy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890
