Allow asterisk to build on bookworm without bookwork-backports (systemd-dev dependency)

[Jonas Smedegaard]

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-11 20:52:12)
> 1. We need to say "We'll do it" in bug #1031046, and the bug needs to
> close.
[...]
> Right now, I believe a DM or DD can action point 1, but I am neither
> of those.

The *only* thing that requires an official DM or DD is signing the final
package that gets released into Debian officially.

Anyone can post to bugreports, with insight and with patch proposals.

Anyone can (request access to) become member of this team.

Anyone in this team has write access to the git repo at Salsa, and can
prepare the packaging sources for official (as well as unofficial)
builds of the package.

It cannot hurt to post commitment statements to that bugreport, but my
expectation is that the security team wants to see some action as well
(or instead).

Here is the developer's view on the Debian packaging of Asterisk:
https://tracker.debian.org/pkg/asterisk

At that page, near the middle, is a listing of 3 CVEs open that affects
bookworm.

It would be helpful if someone had a look at those.  E.g. look into
whether it looks feasable to backport some fix, and if perhaps someone
has already done that somewhere - and track those findings in a
bugreport - so locate an existing bugreport related to the CVE or create
a new bugport otherwise, and then post findings to that bugreport.


> 2. Asterisk gets promoted to testing automatically?

Yes, once no release critical bugs exist for the package, it trickles
from unstable to testing automatically - until the freeze.

> 3. If we make it to the freeze, it could be included in Trixie?

Yes, if it is in testing by the time of the freeze, and it stays in
testing during the freeze, it gets automatically included with next
stable release.

> 4. We backport and apply patches to testing every time a CVE comes up.

Yes, but not only for testing, also for stable and oldstable.

This is the task that requires attention now, to convince the security
team that Asterisk is properly cared for enough to likely become cared
for throughout the full lifecycle of a release.

> 5. We continue applying patches and these land in testing, then get
> promoted to stable?

Not sure how 4) and 5) are any different.  Yes, it is an iterative
process.  it continues, on and on, and sometimes Debian draws a line in
the sand and calls that "stable" or "oldstable", but maintenance means
keep going.

> For point 3 I don't know exactly where patches are applied, since the
> current pkg-voip-team salsa repo only has branches for unstable
> (debian/latest)?

We crate more branches as needed.  E.g. debian/oldstable, branched off
at the point in debian/latest where the current package in oldstable was
last tracked in git.


> I found another repo from the LTS team which seems to be where another
> copy of asterisk is maintained (but I think if a package goes to the
> LTS team, then it's on the bubble of bring dropped from stable).

We are not the LTS team.

If you join the LTS team, then they might want you to use a workflow
that they've established - e.g. so that different team members can
easily take over if you some day loose interest.  Similar here: I might
be stubbornly wanting to do things some particular way, because I want
to be able to take over if you loose interest at some point - but on the
other hand, I really want more hands on deck, so I would be foolish not
to listen if you wildly disagree with me on something - we are supposed
to be a team (and I have for far too long been a lone wolf here, so
might have grown bad habbits).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private