Bug#1014403: RFH: slony1-2 -- replication system for PostgreSQL

[Christoph Berg]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian PostgreSQL Maintainers 

Control: affects -1 src:slony1-2

I request assistance with maintaining the slony1-2 package.

The package is in maintenance mode upstream with very little activity,
but the Debian integration needs work, especially #1003609 and
possibly a deeper look on how to run the testsuite(s).

The package description is:
 Slony-I is an asynchronous master-to-multiple-slaves replication system
 for PostgreSQL with cascading and slave promotion.
 .
 This package contains the support functions that are loaded into the
 PostgreSQL database server.  It needs to be installed on the hosts where
 the database server nodes are running.  This package works with version
 14 of the PostgreSQL server; you need the package that corresponds to
 the version of your database server.
 .
 The actual replication daemon and the administration tools are in the
 package slony1-2-bin.  This package is useless without slony1-2-bin installed
 somewhere in the network.

Christoph

Bug#1014406: ITP: oci-seccomp-bpf-hook -- OCI hook to trace syscalls and generate a seccomp profile

[Domenico Andreoli]

Package: wnpp
Severity: wishlist
Owner: Domenico Andreoli 

* Package name: oci-seccomp-bpf-hook
  Version : 1.2.5-1
  Upstream Author : Valentin Rothberg, Daniel J. Walsh, et al.
* URL : https://github.com/containers/oci-seccomp-bpf-hook
* License : Apache-2.0
  Programming Lang: Go
  Description : OCI hook to trace syscalls and generate a seccomp profile

 This project provides an OCI hook to generate seccomp profiles by
 tracing the syscalls made by the container. The generated profile
 would allow all the syscalls made and deny every other syscall.

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Re: Help needed with a dh_shlibs failure on non amd64 platforms

[Simon McVittie]

On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote:
> All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
> package. They are added to the debian/libns3.36/DEBIAN/shlibs

Independent of the dh_shlibdeps failure that was already diagnosed, if
these libraries are public (i.e. other packages in Debian are allowed to
link against them) and the SONAMEs of the libraries are of the form
libns3-*.so.36.1, then the binary package that contains them should
probably be called something like libns3-36.1, rather than libns3.36.

(Either that, or they should be split up into one binary package per
library, named like libns3-bridge36.1 and so on, by mechanically
transforming their SONAMEs according to the convention documented
in Policy - but I can understand why you would prefer not to do that when
there are a large number of libraries with matching versioning.)

Otherwise, when the SONAMEs jump from libns3-*.so.36.1 to libns3-*.so.36.2
in a future version, any dependent packages that require libns3-*.so.36.1
would be broken by upgrading libns3.36 to a version that no longer contains
libns3-*.so.36.1.

> If you wonder, the cmake macro to define and build a library is in 
>   ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
> I already had to patch it to support Debian:
> https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/library-soversion.diff
> This patch is ugly for now, but I'm already discussing with upstream so that
> they integrate the spirit of this patch to their code. They are receptive.

If you're giving advice to upstream, it's important to be aware of
whether the libraries are private (only to be used by other binary
packages within the same source package, like samba-libs or
libsystemd-shared) or public (with a -dev package that can validly be
used by other source packages, like libsmbclient or libsystemd0 or any
typical shared library like GTK or Qt). The correct advice to give to an
upstream for private shared libraries is not the same as the correct
advice for public shared libraries.

smcv

Bug#1014415: ITP: dispatch -- incident management tool

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: dispatch
  Version : 20220607
  Upstream Author : Netflix
* URL : https://github.com/netflix/dispatch
* License : Apachev2
  Programming Lang: Python
  Description : incident management tool

Dispatch helps effectively manage (security) incidents by deeply integrating
with existing tools used throughout an organization (Slack, GSuite, Jira,
etc.,) Dispatch is able to leverage the existing familiarity of these tools to
provide orchestration instead of introducing another tool.

This means you can let Dispatch focus on creating resources, assembling
participants, sending out notifications, tracking tasks, and assisting with
post-incident reviews; allowing you to focus on actually fixing the issue!

Re: faker,ruby-faker: error when trying to install together

[Timo Röhling]

On Mon, 23 May 2022 01:58:56 +0200 Andreas Beckmann  wrote:

Package: faker,ruby-faker
Severity: serious
Tags: sid bookworm
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 0.9.3-0.1
Control: found -1 2.20.0-1

[...]
Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/bin/faker

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package.

I'm posting to d-devel because I failed to make contact with the
Ruby Team directly:

ruby-faker primarily ships a Ruby module while faker's sole purpose
is the faker executable, so I believe ruby-faker should yield.
There are two reverse dependencies:

- ruby-devise-two-factor builds fine without /usr/bin/faker in
  ruby-faker

- ruby-omniauth-openid-connect FTBFS for unrelated reasons with and
  wihout /usr/bin/faker

If the Ruby Team agrees with my analysis, I'd appreciate it if
someone could upload a fixed version (I am not a team member).


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: faker,ruby-faker: error when trying to install together

[Antonio Terceiro]

On Tue, Jul 05, 2022 at 06:44:15PM +0200, Timo Röhling wrote:
> On Mon, 23 May 2022 01:58:56 +0200 Andreas Beckmann  wrote:
> > Package: faker,ruby-faker
> > Severity: serious
> > Tags: sid bookworm
> > User: trei...@debian.org
> > Usertags: edos-file-overwrite
> > Control: found -1 0.9.3-0.1
> > Control: found -1 2.20.0-1
> > 
> > [...]
> > Here is a list of files that are known to be shared by both packages
> > (according to the Contents file for sid/amd64, which may be
> > slightly out of sync):
> > 
> >   /usr/bin/faker
> > 
> > This bug is assigned to both packages. If you, the maintainers of
> > the two packages in question, have agreed on which of the packages will
> > resolve the problem please reassign the bug to that package.
> I'm posting to d-devel because I failed to make contact with the
> Ruby Team directly:
> 
> ruby-faker primarily ships a Ruby module while faker's sole purpose
> is the faker executable, so I believe ruby-faker should yield.
> There are two reverse dependencies:
> 
> - ruby-devise-two-factor builds fine without /usr/bin/faker in
>   ruby-faker
> 
> - ruby-omniauth-openid-connect FTBFS for unrelated reasons with and
>   wihout /usr/bin/faker
> 
> If the Ruby Team agrees with my analysis, I'd appreciate it if
> someone could upload a fixed version (I am not a team member).

I just did that. Remember that you need to add Breaks:/Replaces: on your
package for upgrades to work.


signature.asc
Description: PGP signature

RFC: Additions to dpkg's Pre-Depends

[Guillem Jover]

Hi!

As per Debian policy §3.5, and given dpkg “Essential: yes” nature, I'm
bringing up the following potential additions to dpkg's Pre-Depends,
and whether there is consensus about each of them individually and
independently.

* libmd-dev
  - Rationale:
src:dpkg currently has its embedded MD5 implementation. On non-Debian
(and derivatives) it will default to use the message digest function
from either the system libmd or libc. I'd eventually like to be able
to remove the embedded code, which is there mostly for Debian. And to
be able to rely on SHA variants, for fsys metadata tracking and
similar (and not have to embed those too). I'd rather not add
support nor link against a crypto library like libgcrypt which might
already be present on the pseudo-essential set (currently, but could
go away easily with the OpenSSL license change), as these functions
are currently used for data integrity rather than for security, and
would/could get broken with stuff like FIPS enabled.

  - Essential/Build-Essential:
AFAIR it is already part of the cross bootstrap set? But not of the
pseudo-build-essential or pseudo-essential sets. Most systems have
it installed via libbsd. On minimal systems it would increase the
installed size by around 80 KiB.

  - Disclosure:
I maintain this in Debian and I'm upstream.

* libaudit-dev
  - Rationale:
This could allow to add Linux audit support to dpkg on package action
events. I've got a branch that might need minor polishing, but could
otherwise be merged.

  - Essential/Build-Essential:
On Linux it is already part of the pseudo-essential set.

* libacl-dev
  - Rationale:
This could allow in the future (either later in 1.21.x or 1.22.x) to
support ACLs as part of the fsys metadata tracking support that is
upcoming.

  - Essential/Build-Essential:
It is already part of the pseudo-essential set.

  - Disclosure:
I maintain this in Debian.

* libcap-dev
  - Rationale:
This could allow to add support to start-stop-daemon (already code
available) to drop POSIX capabilities. And also in the future (either
later in 1.21.x or 1.22.x) to support fsys POSIX capabilities as part
of the fyss metadata tracking support that is upcoming.

  - Essential/Build-Essential:
On Linux it is already part of the pseudo-essential set.

* libzstd-dev
  - Rationale:
This could allow to add zstd support for .debs via the library. This
is mostly to leave the door open to that possibility, as I'm still
pondering whether to perhaps add the support in Debian via the CLI
and just add those via Recommends or similar. Also there are still
concerns about the library and I have to note I'm rather unhappy
with how Ubuntu pushed this, and diverged the .deb ecosystem,
forcing upstream's hand here. :(
More details at .

  - Essential/Build-Essential:
On Linux it is already part of the pseudo-essential set.

Thanks,
Guillem