Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > Hi Steve, > On 05-01-2024 17:36, Rene Engelhard wrote: > > Also a problem is that experimental also might already contain totally > > unrelated updates like new upstream versions... > I share this worry. Have you thought about how to handle the cases where you > don't have experimental to upload to? How big is this problem? > Another worry, how will you provide the required changes to the maintainers > of the packages? Via BTS? For those working on salsa: MR? Both? Something > else? Obviously we should not end in the situation that a new upload goes > back to the old name (or are the ftp-masters so keen on this transition that > that won't happen? But what about newer versions with the old name already > in experimental, conform the former worry?). I've seen NMU's being ignored > by subsequent uploads by the maintainer, even when they fixed RC issues > which were then reintroduced. I would intend to provide diffs via the BTS. This remains the standard policy for NMUs in Debian per the Developer's Reference, and as far as I know has worked effectively for all such previous ABI transitions. I think it is reasonable to expect maintainers to pay attention to their bug mail as our defined Debian process. I don't think it would be reasonable to expect people working on cross-archive toolchain transitions to cater to individual maintainer preference in this regard. If a maintainer ignores the NMU and drops the rename, they'll be introducing a new library transition again on 32-bit archs. Won't they also be caught again in binary NEW, for those packages that don't have the same runtime library package name in experimental? It seems to me there's ample opportunity to catch such mistakes if they happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1060291: ITP: python-nh3 -- Python bindings to the ammonia HTML sanitization library.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-nh3 Version : 0.2.15 Upstream Contact: * URL : https://github.com/messense/nh3 * License : MIT Programming Lang: Pytthon Description : Python bindings to the ammonia HTML sanitization library. NH3 is an HTML sanitizing library that escapes or strips markup and attributes based on a white list. NH3 can also linkify text safely, applying filters that Django's urlize filter cannot, and optionally setting rel attributes, even on links already in the text. . NH3 is intended for sanitizing text from untrusted sources. If you find yourself jumping through hoops to allow your site administrators to do lots of things, you're probably outside the use cases. Either trust those users, or don't. Bleach is deprecated, NH3 is seen a valid successor. NH3 is neead to package the latest version of 'python-readme-renderer' https://github.com/mozilla/bleach/issues/698 https://daniel.feldroy.com/posts/2023-06-converting-from-bleach-to-nh3
Re: MBF: Switching Build-Depends from systemd/udev to systemd-dev
Am 04.01.24 um 18:57 schrieb Michael Biebl: Hi fellow DDs, due to popular request, the pkg-config files systemd.pc and udev.pc have been split into a separate arch:all package named systemd-dev. A lot of packages Build-Depend on systemd and/or udev to get the paths such as systemd_system_unit_dir or udev_dir for installation of upstream provided service files or udev rules. To ease the transition to this new systemd-dev package, the systemd and udev package currently have a Depends on systemd-dev to not cause any unnecessary build failures. We would like to get rid of this dependency though in time for trixie. Thus this MBF. Given that this has been rather quiet, I'd proceed with filing the bug reports the upcoming weekend. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 04:12:42PM +0100, Julian Andres Klode wrote: > > - once these packages have all cleared binary NEW, the new dpkg defaults > > will be uploaded to unstable > What happened to the plan to workaround this by doing dak database > shenanigans prior to uploading to avoid binary-NEW altogether, that > I chatted about with mhy/#debian-ftp and you? Did that not work out? That wasn't called out here but is part of the implementation details of the plan. The intention is still to go through binary NEW in experimental before copying to unstable, because it will take time to get all the binary uploads done (longer than it will take to get the sourceful uploads to unstable done), so it's better to stage in experimental to minimize the window in unstable when uploads can be broken. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hey Steve,
On Sat, Jan 06, 2024 at 07:38:42PM -0800, Steve Langasek wrote:
> On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> > Hi,
>
> > Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > > default
> > > > > flags
> > > [...]
> > > What about the suggestion to not push changes to experimental for packages
> > > that already have new versions in experimental, and do the binary package
> > > renames in unstable instead, leaving the package in experimental alone?
>
> > How does that play together with the needed dpkg only in experimental?
>
> > You can't build stuff for unstable involving experimental packages (except
> > manually with binary upload, which would block testing migration)
>
> The ordering here would be:
>
> - dpkg will be uploaded to experimental with 64-bit time_t in the default
> flags
>
> - the source packages which need an ABI change
> ("source-packages"+"lfs-and-depends-time_t") and do not already have
> versions in experimental, will have sourceful NMUs to experimental with
> the new binary package names in order to clear binary NEW, in coordination
>
> - once these packages have all cleared binary NEW, the new dpkg defaults
> will be uploaded to unstable
What happened to the plan to workaround this by doing dak database
shenanigans prior to uploading to avoid binary-NEW altogether, that
I chatted about with mhy/#debian-ftp and you? Did that not work out?
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
signature.asc
Description: PGP signature
Re: Policy: should libraries depend on services (daemons) that they can speak to?
On 2024-01-08 09:57:16 +0100 (+0100), Dylan Aïssi wrote: [...] > Please don't do that. At least one pipewire module depends on libpulse0 > (libpipewire-module-pulse-tunnel from the libpipewire-0.3-modules package). > But, pulseaudio is useless in this case that means it will be unnecessarily > pulled. Worse than useless, pipewire-audio declares a conflict with the pulseaudio (daemon) package since 0.3.60-1 (so including bookworm). I've already encountered a third-party package that declares a depends on pulseaudio and is uninstallable for that reason, or would require uninstalling the pipewire audio stack at least. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#1060265: ITP: python-django-ansible-base -- Reusable base for Ansible applications using Django
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: python-django-ansible-base Version : 0.1.0 Upstream Contact: John Westcott IV * URL : https://github.com/ansible/django-ansible-base * License : Apache-2.0 Programming Lang: Python Description : Reusable base for Ansible applications using Django This Python library provides a set of classes for building Ansible applications using the extensible configurability of Django. It currently brings tools for authentication, filtering, validation, management commands, logging, models. . Django is a high-level Python web development framework. This package is maintained by python team, and is a dependency of awx.
Re: Policy: should libraries depend on services (daemons) that they can speak to?
On 07/01/2024 19:39, Ansgar wrote: > I would like to extend Debian Policy on libraries depending on services > (daemons) that they can speak to. Generally speaking, if an application is using a client-server model and there's no technical requirement for the client and server to be running on the same machine, the client package should absolutely *not* depend on the server package. As an example, if I install some PostgreSQL libraries on my laptop so I can manage a bunch of PostgreSQL servers I maintain, I clearly don't need or want a full PostgreSQL server installed on my laptop. This also holds true for audio daemons like PulseAudio. The server component is not required for the client libraries to function, so the latter should not depend on the former. The argument is less clear in this case since the majority of users will likely be running client and server on the same box, but I believe the logic is the same. A package's "Depends" field is for installing packages that are _required_ in order for the requested package to function, and shouldn't be used to provide user convenience based on an assumed use case. That's really what "Suggests" is for. If we have high confidence that another package is required for a dominant use case we could go as far as "Recommends", but we should only use "Depends" for additional packages required for *all* of a package's use cases. Best regards, Dale Richards
Re: Policy: should libraries depend on services (daemons) that they can speak to?
On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote: > Maybe the question is also a bit .. "it depends". ... > So that users actually likely get a system that works? I think the fact that we argue about this every few years, with no simple conclusion, is adequate evidence that the answer is "it depends". We're balancing two competing factors: "make the system work by default" implies that *something* needs to be responsible for pulling in required services at least some of the time, while "make the system flexible" implies that we should not be pulling in all of the services all of the time. In some of the distributions we are competing with, the default answer would be "install no services, the user is expected to know what they are doing". I think that would be doing our users a disservice: we cannot expect new users of Linux to "just know" that in practice, to get what a new user would consider to be a working desktop system, they are going to need dbus-daemon (or dbus-broker), Pipewire (or PulseAudio or JACK or something), logind (or elogind), xdg-desktop-portal, an implementation of o.fd.Notifications, an implementation of o.fd.Secrets and so on. Meanwhile, some distributions are more opinionated than Debian, have chosen a distro-wide preferred implementation for each swappable component, and make it quite difficult to exclude those components or swap them for alternatives. We probably don't want to do that either. See also the thread starting at https://lists.debian.org/debian-devel/2019/08/msg00278.html and in particular my reply https://lists.debian.org/debian-devel/2019/08/msg00291.html, where our choices are "pull in a dependency" or "user configuration changes are not saved". In response to that thread, I proposed a debhelper patch in #934893 to make it possible to break the dependency chain in what I felt would be the least inappropriate place, and that change was wontfix'd. If libraries that pull in services are considered to be a serious problem, one option would be for "the big desktop environments" (GNOME, KDE, etc.) to have Depends or Recommends on a reasonable set of services that users of those environments will typically want, and then drop dependencies on those services from lower down the stack. However, I suspect that the result of that action would be RC bug reports from users who have pieced together their own unique desktop environment from individual components (or just installed the desktop environment without Recommends), installed one leaf application from GNOME or KDE, and found that the application does not work correctly (or at all) without a service that this particular user's customized desktop environment does not depend on. We cannot have a policy that libraries must not depend on the daemons that are sometimes necessary to make them work as designed, but at the same time have a policy that says missing dependencies are a RC bug that maintainers are expected to drop everything to fix immediately. Demanding that maintainers do impossible things will not give us better software, it will just give us burned-out maintainers. smcv
Bug#1060253: ITP: gnome-model-thumbnailer -- 3d model thumbnailer for GNOME
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gnome-model-thumbnailer Version : 0+git20240108+ds Upstream Authors: Luke Benstead URL : https://gitlab.com/Kazade/gnome-model-thumbnailer/ * License : MIT Description : 3d model thumbnailer for GNOME This is a thumbnailer for the GNOME desktop that will generate previews of 3D models in your file manager (e.g GNOME Files). Currently it previews .obj, .md2, .md3, and .ms3d.
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Hi, Le dim. 7 janv. 2024 à 20:40, Ansgar a écrit : > > 1. libpulse0 & friends > -- > > libpulse0 is a client library for the Pulseaudio server. It doesn't do > much without pulseaudio. > > Q: Should libpulse0 have Depends: pulseaudio? Please don't do that. At least one pipewire module depends on libpulse0 (libpipewire-module-pulse-tunnel from the libpipewire-0.3-modules package). But, pulseaudio is useless in this case that means it will be unnecessarily pulled. Best regards, Dylan
Re: Policy: should libraries depend on services (daemons) that they can speak to?
On 2024-01-07, Ansgar wrote: > 1. libpulse0 & friends > -- > If the answer is "yes", this would result in an application that can > output audio via Pulseaudio or Jackd and linking the respective > liubraries pulling in *both* Pulseaudio and Jackd (and possibly other > sound servers as well). I'm a bit .. it depends. But it might end up being delegated to the applications to do it manually maybe. Assuming an audio providing program (netradio streamer or something) that just does pulseaudio. No backends. no configuration. Just pulse. I would not expect users to figure out that a Suggests: pulseaudio was the missing bit needed to get the application to actually work. On the other hand > 3. The general case > --- I'm currently investigating an upstream bug report from a sister distribution. A document reader links thru various intermediate steps to libspeech2, a library from src:speech-dispatcher to talk to speech-dispatcher daemon to do text-to-speech. And libspeech2 (at least thru the intermediates) ends up not giving me an easy failure to act upon. How do the distribution maintainer of the document reader ensure that the users know that they need speech-dispatcher around for that to work? Maybe the question is also a bit .. "it depends". Assuming 10 different sound servers, one might be the one we as a distribution considers the default. Maybe the default one should have libfoo: Recommends: foo. and the non-defaults should have libbar: Suggests: bar So that users actually likely get a system that works? I guess it is a tradeoff between extra-cruft-on-systems and likely-that-systems-work, and we need to draw a line somewhere. I might also be slightly biased towards adding slightly extra cruft on systems to ensure they work because of the package collection I'm involved in (KDE and friends) as opposed to people maintaining packages mostly used by server administrators, maybe even container-heavy server administrators. /Sune
