Work-needing packages report for Jul 9, 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: 1222 (new: 7) Total number of packages offered up for adoption: 203 (new: 1) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: brandy (#990610), orphaned 6 days ago Description: BBC BASIC V interpreter Installations reported by Popcon: 49 Bug Report URL: https://bugs.debian.org/990610 cd-circleprint (#990611), orphaned 6 days ago Description: prints round cd-labels Installations reported by Popcon: 33 Bug Report URL: https://bugs.debian.org/990611 ltris (#990613), orphaned 6 days ago Description: very polished Tetris clone with CPU opponents Installations reported by Popcon: 343 Bug Report URL: https://bugs.debian.org/990613 otp (#990615), orphaned 6 days ago Description: Generator for One Time Pads or Passwords Installations reported by Popcon: 89 Bug Report URL: https://bugs.debian.org/990615 perl-tk (#990616), orphaned 6 days ago Description: Perl module providing the Tk graphics library Reverse Depends: algotutor cd-circleprint clusterssh colplot divxcomp fcm libconfig-model-tkui-perl libdevel-ptkdb-perl libpdl-io-hdf5-perl libpoe-loop-tk-perl (18 more omitted) Installations reported by Popcon: 16242 Bug Report URL: https://bugs.debian.org/990616 ploticus (#990612), orphaned 6 days ago Description: script driven business graphics package Reverse Depends: libploticus0-dev Installations reported by Popcon: 128 Bug Report URL: https://bugs.debian.org/990612 tart (#990614), orphaned 6 days ago Description: versatile and feature-rich email signature generator Installations reported by Popcon: 9 Bug Report URL: https://bugs.debian.org/990614 1215 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: propellor (#990802), offered yesterday Description: property-based host configuration management in haskell Reverse Depends: libghc-propellor-prof propellor Installations reported by Popcon: 46 Bug Report URL: https://bugs.debian.org/990802 202 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 999 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: 93448 Bug Report URL: https://bugs.debian.org/910917 asciio (#968843), requested 320 days ago Description: dynamically create ASCII charts and graphs with GTK+2 Installations reported by Popcon: 71 Bug Report URL: https://bugs.debian.org/968843 aufs (#963191), requested 383 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 11629 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1681 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1214 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3574 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 601 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1549 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 2312 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 189 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: 981 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 123 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted)
Need help with Multi-Arch in systemd
Hi,
a couple of days ago, the following bug report was filed against systemd
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
I'm quoting the relevant parts
I noticed that systemd-machined was failing to start on an arm64
box. This box had armhf enabled, and turns out systemd had been
cross-graded over to systemd:armhf[*]. It still had
systemd-container:arm64 installed, so now I had an arm64
/lib/systemd/systemd-machine, but an armhf
/lib/systemd/libsystemd-shared-244.so.
libsystemd-shared-244.so is from the systemd package. Since systemd is
marked Multi-Arch: foreign, systemd:armhf was able to incorrectly
satisfy systemd-container:arm64's dependency on systemd.
The systemd package provides a package private library
/lib/systemd/libsystemd-shared-{source:Version}.so, which is used by
binaries that are built from src:systemd. Some of those binaries are
split into separate binary packages, like systemd-container.
Since both systemd is marked as Multi-Arch: foreign, it can happen that
we get this architecture mismatch.
Asking on #debian-systemd, Marco d'Itri suggested, that we move
libsystemd-shared into a separate binary package. This would only help,
if we moved libsystemd-shared into a Multi-Arch location (which means,
we'd have to carry a patch against upstream). It would also mean, that
on every new upstream release, systemd would have to go through NEW.
So I'm not very keen on doing that.
Option 2 would be to drop Multi-Arch: foreign from systemd. This would
mean, that packages like libpam-systemd/libnss-systemd can no longer be
installed for a foreign architecture (even though those modules only use
architecture independent interfaces of systemd).
Option 3 is something I came up with after reading the Multi-Arch
related wiki pages:
https://salsa.debian.org/systemd-team/systemd/-/commit/c379461a14dcd13e0b625bd8faabbcf7fb3d19d6
It would mean marking systemd as Multi-Arch: allowed. And packages that
only use architecture interfaces of systemd would have to use the :any
annotation.
I would appreciate feedback, if option 3 is proper solution or not, or
if there are other, better alternatives. If we go with option 3, should
I inform all rdeps of systemd to update their dependency accordingly,
i.e. do a MBF?
Currently, I only see interpreters like perl, use M-A: allowed, so I'm
not sure if I'm misusing this feature.
Regards,
Michael
OpenPGP_signature
Description: OpenPGP digital signature
Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")
On Mon, Jul 05, 2021 at 12:31:10PM +, Holger Levsen wrote:
> On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote:
> > > Do you have plans to support publishing builds only if they've produced
> > > bit by bit identical results on several builders? IOW, do you plan to
> > > support reproducible builds? :)
> >
> > There is no specific support for reproducible builds. Currently,
> > buildinfo files can be uploaded and are kept, with the metadata stored
> > in the DB. but nothing is done yet with those.
>
> yeah :/
>
> > But reproducibility can be tested in GItlab jobs, before the upload.
>
> that's nice, but rather theoretic (however common it is today) in practice :)
> It would be really interesting / a game changer, to have a publishing option
> which would only allow publishing of builds proven in practice to be
> identical.
It's actually fairly easy to do that:
- Create two runners, with different tags (e.g., one tagged "build1",
and one tagged "build2"). One can be a docker runner, the other a
shell runner, just to keep things interesting.
- Create two jobs that build the same source in ways that might trigger
reproducability issues (I'm sure you're better at this than me). Make
sure that they don't store their artifacts in the same location (e.g.,
one job runs "dcmd mv ../*.changes products/build1/", and the other
one does "dcmd mv ../*.changes products/build2/").
- Have a third job that depends on both the above two jobs, and that
runs diffoscope over the artifacts of both jobs. If and only if the
diffoscope doesn't reveal any issues, run dput to upload the packages.
I think the salsa-CI team can easily add support for this to their
generic pipeline...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
