On 09.10.25 10:44, Jonas Smedegaard wrote:
My point was another: When asterisk is properly maintained, there is no
need for duplicating that work by custom-backporting it - regardless if
sponsored.
Which "custom backporting" are you talking about? given that the note
explicitly says
It built without changes,
So which duplicate work is there? I don't see any. It's literally one
single argument to pbuilder-or-whatever that otherwise wouldn't be
there. (Assuming that your build infrastructure is set up to facilitate
that kind of thing.)
The current Asterisk was tested. It works. Great!
Somebody stepped up and did that building and testing. Great!
Whether or not they got paid for that IMHO does not matter IMHO. Like,
at all. The important part is that the work gets done and ends up in
Debian. Which this particular work doesn't even need to, because it
already is, because of the "without changes" thing.
The reason I posted my remark was that I find it troublesome that it is
difficult to gather volunteers to maintain asterisk officially in
Debian, and I don't see that getting any easier by sponsors paying for
bypassing that.
While it'd be nice to ask sponsors to please finance the ongoing
maintenance of Asterisk packaging instead of one-shot(?) tests, I
disagree insofar as me volunteering and you getting paid for that work,
or vice versa, is not mutually exclusive.
Also, please read that sponsorship notice again..:
The tests were made and Sponsored by Linuxhotel.
*Tests* were done and sponsored by Linuxhotel. Even in 2025 stress
testing a phone system requires, well, a phone system. Ideally one
that's large enough to be interesting. Plus presumably some costs for
the actual phone calls and/or some manpower to do these calls.
There is no "bypassing" involved here. They just want a working phone
system running on Trixie. It's kindof presumptuous to *expect* them to
do the same testing on Unstable instead. Companies typically don't run
their phone system on Sid.
Maybe we can now finally close this bug and it'll built without changes
in Forky too, which is kindof what we want, don't you think? By now the
procedure to follow when (not if, unfortunately) the next security
announcement hits is sufficiently well-documented that one of the people
who already volunteered to care for this beast will step up.
--
-- regards
--
-- Matthias Urlichs
