Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Russ, On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: > Ansgar writes: > > Debian going out of its way to tell derivative users to switch back from > > merged-/usr to split-/usr is the *opposite* of trying to make things as > > smooth for them as possible. > > Yes, I agree with that part and I think I objected to that at the time. > Nonetheless, one bad decision doesn't mean that it is Debian policy that > we don't care about derivatives or their users. I think we made a mistake > there which is not in alignment with our ideals or our goals. We should > try to reverse that mistake, not double down on it. My impression is that the tech-ctte disagrees on this point and would not want to reverse the mistake, but double down on it (in your words). Or rather my impression is that they would like to avoid any decision on the dpkg mess situation. (Though not making a decision when asked is of course also an explicit decision.) So let me summarize Debian's "official" position as I understand it: we do *NOT* care how dpkg's recommendations will break derivative installations at all; if systems become unbootable, cause data loss, ... now or in the future that is explicitly fine. Ansgar
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, 26 May 2023 at 00:27, Roger Lynn wrote: > > On 21/05/2023 07:00, James Addison wrote: > > On Fri, 19 May 2023 at 22:58, Ansgar wrote: > >> One of the problems with popcon is that it draws too much attention to > >> old releases which isn't really interesting when talking about future > >> developments. If one looks at arch usage per release (as reported to > >> popcon) one gets this table: > >> > >> | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | > >> |++-++--+--| > >> | alpha | 1 | || |4 | > >> | amd64 | 9090 | 17156 | 41137 | 108145 |14800 | > >> | arm64 || 1 | 93 | 937 | 203 | > >> | armel | 21 | 47 | 67 | 68 | 10 | > >> | armhf | 7 | 18 |216 | 429 | 49 | > >> | hppa || || |8 | > >> | hurd-i386 || ||4 |6 | > >> | i386 | 1318 |1231 | 1495 | 3042 | 168 | > >> | ia64 || || |3 | > >> | kfreebsd-amd64 | 2 | || | | > >> | m68k || 1 || |4 | > >> | mips | 2 | | 6 | | | > >> | mips64el || | 6 |4 | | > >> | mipsel | 2 | 1 | 7 | | | > >> | powerpc| 13 | 1 | 1 |1 | 18 | > >> | ppc64 || ||1 | 28 | > >> | ppc64el|| 5 | 16 | | 12 | > >> | riscv64|| || | 15 | > >> | s390x || ||8 |3 | > >> | sh4|| || |1 | > >> | sparc64|| || | 11 | > >> | x32|| || |2 | > >> |++-++--+--| > >> | ∑ | 10456 | 18461 | 43044 | 112639 |15345 | > >> #+TBLFM: @>$2..@>$>=vsum(@I..II) > >> > >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. > >> Also interesting is that arm64 has taken over i386 on bookwork/sid. > >> > >> We don't know how many people downloaded i386 instead of amd64 as they > >> have an Intel CPU. > >> > >> What is also not clear is the bias of systems having popcon enabled at > >> all (it seems to be mostly desktop systems) and how it looks on the > >> total population. > > > > Thanks, those are better statistics (and good notes about their > > limitations). > > > > I may be playing devil's advocate, but I do also read from those that > > the i386 install-base, even dwindled as it has to ~1%, remains more > > popular than many other architectures (within whatever dimension of > > users enable popcon) where we do provide install images, and then that > > those users tend to upgrade to the latest i386 release of Debian that > > they can -- and/or that despite the percentage-of-total trend > > reducing, the absolute population of those i386 users is growing (I > > guess the former is the larger contributing factor, but it's hard to > > determine from the numbers only). > > The popcon graphs clearly show that the absolute number (not proportion) of > i386 reports flattened off in 2008 at about 65000, when AMD64 became > popular. The number of i386 reports has been falling since 2014, and is now > about 1, most of which are from old releases (oldstable or older). It > seems likely that the number of i386 reports from stable will be overtaken > by ARM64 during the period of Bookworm. Thanks Roger. I concede that the absolute number of i386 popcon reports has been falling; this graph makes that clear[1]: https://web.archive.org/web/20221223090933/https://popcon.debian.org/stat/sub-i386.png Also, yep, it does seem possible that i386's position in terms of total popcon reports could fall into third place behind AMD64 and ARM64 over the next two years or so. Is an architecture's ranking position within popcon reports a significant factor in whether it should be installer-supported? Or is it perhaps only a secondary indicator and there are other considerations that are more important? (for example, whether we have volunteers keen to support it..) An aside: the trend for ARM64 reports appears to include a few steep increments followed by pauses. I'm left wondering whether those correspond to additional hardware support, arrival of popular packages in the ARM64 archive, or other factors[2]: https://web.archive.org/web/
Work-needing packages report for May 26, 2023
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: 1207 (new: 8) Total number of packages offered up for adoption: 156 (new: 0) Total number of packages requested help for: 58 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: binutils-msp430 (#1036351), orphaned 6 days ago Description: Binary utilities supporting TI's MSP430 targets Reverse Depends: gcc-msp430 gdb-msp430 Installations reported by Popcon: 62 Bug Report URL: https://bugs.debian.org/1036351 coco-cs (#1036426), orphaned 5 days ago Description: Coco/R Compiler Generator (C-Sharp Version) Installations reported by Popcon: 6 Bug Report URL: https://bugs.debian.org/1036426 coco-java (#1036427), orphaned 5 days ago Description: Coco/R Compiler Generator (Java Version) Installations reported by Popcon: 7 Bug Report URL: https://bugs.debian.org/1036427 gcc-msp430 (#1036350), orphaned 6 days ago Description: GNU C compiler (cross compiler for MSP430) Installations reported by Popcon: 53 Bug Report URL: https://bugs.debian.org/1036350 gdb-msp430 (#1036349), orphaned 6 days ago Description: The GNU debugger for MSP430 Installations reported by Popcon: 34 Bug Report URL: https://bugs.debian.org/1036349 grub-splashimages (#1036339), orphaned 6 days ago Description: collection of GRUB splashimages Installations reported by Popcon: 221 Bug Report URL: https://bugs.debian.org/1036339 grub2-splashimages (#1036338), orphaned 6 days ago Description: collection of GRUB2 splashimages Installations reported by Popcon: 555 Bug Report URL: https://bugs.debian.org/1036338 msp430-libc (#1036352), orphaned 6 days ago Description: Standard C library for TI MSP430 development Installations reported by Popcon: 56 Bug Report URL: https://bugs.debian.org/1036352 1199 older packages have been omitted from this listing, 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 156 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 1685 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 debian-edu-router-deployserver (125 more omitted) Installations reported by Popcon: 97211 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 444 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core (24 more omitted) Installations reported by Popcon: 194185 Bug Report URL: https://bugs.debian.org/1006872 autopkgtest (#846328), requested 2367 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1163 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 4260 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 596 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 2235 days ago Description: Rust package manager Reverse Depends: dh-cargo python3-setuptools-rust rust-all Installations reported by Popcon: 2928 Bug Report URL: https://bugs.debian.org/860116 chromium (#1016047), requested 303 days ago Description: web browser Reverse Depends: chromium chromium-driver chromium-l10n chromium-shell node-puppeteer qunit-selenium x2gothinclient-minidesktop Installations reported by Popcon: 24618 Bug Report URL: https://bugs.debian.org/1016047 courier (#978755), requested 875 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: 753 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 809 days ago Description: new mai
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On 21/05/2023 07:00, James Addison wrote: > On Fri, 19 May 2023 at 22:58, Ansgar wrote: >> One of the problems with popcon is that it draws too much attention to >> old releases which isn't really interesting when talking about future >> developments. If one looks at arch usage per release (as reported to >> popcon) one gets this table: >> >> | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | >> |++-++--+--| >> | alpha | 1 | || |4 | >> | amd64 | 9090 | 17156 | 41137 | 108145 |14800 | >> | arm64 || 1 | 93 | 937 | 203 | >> | armel | 21 | 47 | 67 | 68 | 10 | >> | armhf | 7 | 18 |216 | 429 | 49 | >> | hppa || || |8 | >> | hurd-i386 || ||4 |6 | >> | i386 | 1318 |1231 | 1495 | 3042 | 168 | >> | ia64 || || |3 | >> | kfreebsd-amd64 | 2 | || | | >> | m68k || 1 || |4 | >> | mips | 2 | | 6 | | | >> | mips64el || | 6 |4 | | >> | mipsel | 2 | 1 | 7 | | | >> | powerpc| 13 | 1 | 1 |1 | 18 | >> | ppc64 || ||1 | 28 | >> | ppc64el|| 5 | 16 | | 12 | >> | riscv64|| || | 15 | >> | s390x || ||8 |3 | >> | sh4|| || |1 | >> | sparc64|| || | 11 | >> | x32|| || |2 | >> |++-++--+--| >> | ∑ | 10456 | 18461 | 43044 | 112639 |15345 | >> #+TBLFM: @>$2..@>$>=vsum(@I..II) >> >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. >> Also interesting is that arm64 has taken over i386 on bookwork/sid. >> >> We don't know how many people downloaded i386 instead of amd64 as they >> have an Intel CPU. >> >> What is also not clear is the bias of systems having popcon enabled at >> all (it seems to be mostly desktop systems) and how it looks on the >> total population. > > Thanks, those are better statistics (and good notes about their limitations). > > I may be playing devil's advocate, but I do also read from those that > the i386 install-base, even dwindled as it has to ~1%, remains more > popular than many other architectures (within whatever dimension of > users enable popcon) where we do provide install images, and then that > those users tend to upgrade to the latest i386 release of Debian that > they can -- and/or that despite the percentage-of-total trend > reducing, the absolute population of those i386 users is growing (I > guess the former is the larger contributing factor, but it's hard to > determine from the numbers only). The popcon graphs clearly show that the absolute number (not proportion) of i386 reports flattened off in 2008 at about 65000, when AMD64 became popular. The number of i386 reports has been falling since 2014, and is now about 1, most of which are from old releases (oldstable or older). It seems likely that the number of i386 reports from stable will be overtaken by ARM64 during the period of Bookworm. Roger
Bug#1036767: ITP: d-spy -- D-Bus explorer and test app for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: d-spy Version: 1.6.0 Upstream Author: Christian Hergert License: GPL-3+ Programming Lang: C Description: D-Bus explorer and test app for GNOME D-Spy is a tool to explore and test end-points and interfaces on the System or Session D-Bus. You can also connect to D-Bus peers by address. . D-Spy was originally part of the GNOME Builder app. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/d-spy D-Spy is a maintained alternative to the D-Feet app. D-Spy uses GTK4 and libadwaita. D-Spy also provides a library that is used to provide its features integrated into the GNOME Builder app. Thanks, Jeremy Bícha
Bug#1036765: ITP: libsyntax-operator-in-perl -- infix element-of-list meta-operator
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-operator-in-perl Version : 0.04 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Syntax-Operator-In * License : Artistic or GPL-1+ Programming Lang: Perl Description : infix element-of-list meta-operator Syntax::Operator::In provides an infix meta-operator that implements a element-of-list test on either strings or numbers. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1036763: ITP: libsyntax-operator-equ-perl -- equality operators that distinguish C
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-operator-equ-perl Version : 0.05 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Syntax-Operator-Equ * License : Artistic or GPL-1+ Programming Lang: Perl Description : equality operators that distinguish C Syntax::Operator::Equ provides infix operators that implement equality tests of strings or numbers similar to perl's eq and == operators, except that they consider undef to be a distinct value, separate from the empty string or the number zero. These operators do not warn when either or both operands are undef. They yield true if both operands are undef, false if exactly one operand is, or otherwise behave the same as the regular string or number equality tests if both operands are defined. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1036754: ITP: spack -- flexible package manager for supercomputer
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: spack Version : 0.20.0 Upstream Authors: Spack Project Developers URL : https://spack.io/ * License : Apache-2.0 or MIT Description : flexible package manager for supercomputer This is a flexible package manager for supercomputer that supports multiple versions, configurations, platforms, and compilers.
Re: i386 in the future
> On 2023-05-19, Steve McIntyre wrote:
> Colin Watson wrote:
> On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
> LB == Luca Boccassi wrote:
LB> +1 for stopping publishing installers for i386, it has been
LB> mentioned many times but it's always worth repeating: electricity
LB> costs to keep running i386 hardware are already way higher than
LB> what it costs to buy a cheap, low-power replacement like a
LB> raspberry pi, that also provides better performance.
I'm living within some 200 km distance from a major hydroelectric
plant, so I can afford being more concerned about freedom than
electricity costs [*]. I admit I haven't researched this question
properly, but my understanding is that while, say, the AMD SB740
chipset from c. 2008 (that my primary box is built on) is very
well-documented (and well supported by free software), many newer
ones are not nearly as much (regardless of their power efficiency.)
Granted, it's amd64, but it's still a 'retro' machine already.
Specifically, while I have little experience with RPis (and SBCs
in general), http://wiki.debian.org/CheapServerBoxHardware
suggests that RPis aren't all that well supported by Debian main.
CSBH> Unsuitable
CSBH> * RaspberryPi: requires nonfree software to start up
CSBH> * RaspberryPi2: requires nonfree software to start up
CSBH> * RaspberryPi3: requires nonfree software to start up
[*] My electricity bill is under 20 USD / month.
>>> Well, maybe not a strong view, but a sense of vague unease--possibly
>>> an ill-informed one. As someone who has used SIMH for "real"
>>> work, I have to ask how someone would conduct an install to a 32-bit
>>> x86 machine running under emulation, assuming no OS on the simulated
>>> machine.
>> I occasionally use 32-bit x86 even today (mostly for not very good
>> historical reasons, but nevertheless), and I do it by using a 32-bit
>> container on a 64-bit x86 machine instead. It's much faster to run,
>> and it doesn't depend on installer support. There are doubtless
>> edge cases where you need a completely separate kernel, but they
>> aren't really ones I run into.
> ACK. For people needing/testing i386 stuff, even just a simple
> debootstrap and {s,}chroot will cover the vast majority of needs.
> That's how we've been building i386 software already for ages in
> Debian already.
> More complex things can be done if needed: loopback mount an image,
Or: attach a disk, partition it, mkfs and mount as needed...
> debootstrap, install a kernel, etc. I don't see this as something
> we should be spending much effort on in the future.
FWIW, I'm using debootstrap to install Debian on my boxes for
something like a full decade now. Personally, I wouldn't be
inconvenienced in the least were Debian to stop providing D-I
images for i386, or any other architecture for that matter.
But I'd rather appreciate if it'd still be possible to run i386
binaries on Debian, including running a full Debian install
on a i386 (i686) machine, real or emulated.
(For i586 and other older platforms, I've found I could happily
rely on NetBSD instead.)
--
FSF associate member #7257 np. Border Line by Paolo Pavan
