Asterisk Maintenance

[tegularius at mail2tor.com]

Hi Jonas,

> Hi Martin,
>
> Quoting Martin Rampersad via Pkg-voip-maintainers (2025-01-10 03:36:12)
>> There is a new version of asterisk available on
>> https://downloads.asterisk.org/pub/telephony/asterisk/
>>
>> I am interested in assisting with maintenance, if someone is planning to
>> bump the
>> unstable version to this latest one, I would be very interested to learn
>> how this is
>> done. I believe there are some simple steps like updating the upstream
>> branch and
>> putting in a change log entry, but there are some steps I don't fully
>> understand, like
>> updating the copyright details and otherwise confirming the new release
>> complies
>> with the Policy.
>>
>> I have forked the repo in salsa under my user account, and I might try
>> to perform
>> the steps as documented in the Team VoIP wiki, and I would appreciate
>> some
>> feedback. Please let me know.
>
> I have now updated asterisk, and wrote down exactly the commands used.
>
> First a command I did (the equivalent of) previously, needed only once:
>
> ```
> gbp clone vcsgit:asterisk
> ```
>
> Also, for the quilt commands below, you want to setup this:
> https://wiki.debian.org/UsingQuilt#Using_quilt_with_Debian_source_packages
>
> Also, for the local* commands (if you are not using one of the other
> many ways to build packages) you will want a few of my /usr/local/bin
> scripts from https://source.jones.dk/bin
>
> With the above, here's what I did:
>
> ```
> gbp import-orig --uscan # import newest upstream release
> tig --all # examine import and get a sense of upstream changes
> quilt push && quilt refresh # repeat until all patches are applied
> quilt pop -a # ...and then unroll the patches again
> ls -la .pc # old habit: 3 files there means all patches are unapplied
> rm -rf .pc # ...which means we can cleanup as git does not like that dir
> git status # check if patch refreshing caused unfuzzing needing a commit
> debian/copyright-check # scan sources for copyright/licensing changes
> git diff # see if we need to update debian/copyright
> gbp dch -a debian && dch -r # generate and refine new changelog section
> git status # check that only changelog and maybe copyright is changed
> git commit -m "update changelog and copyright hints" -a
> localcowbuilder-update sid # update local buil environment
> localgitcowdebuild sid # build the package
> ```
>
> When built, I always keep the older build around and compare contents:
>
> ```
> debdiff -wt asterisk_22.1.{0,1}*_amd64.changes | less -R
> ```
>
> Since changes look sensible, and the upstream source code changes were
> minimal, I sign and release the package:
>
> ```
> debsign asterisk_22.1.1*_source.changes
> dput asterisk_22.1.1*_source.changes
> ```
>
> ...and since that went well, I sign and push the git repo as well:
>
> ```
> gbp tag && gbp push
> ```
>
> That's it.
>
> Now, if you want to try replicate at least the first half of the above,
> then I recommend that after you've cloned the repo you configure it to
> temporarily not have its remote, to not accidentally push your
> experimental mess to the shared repo.
>
> If a `gbp import-orig` goes wrong or you just (like now) want to dial
> back changes for other reasons, then beware that it has touched 3
> branches and added a tag, which can be reverted like this:
>
> ```
> tig --all # get an overview of involved branches and tags
> git checkout upstream/latest
> git reset --hard upstream/22.0.0_dfsg+_cs6.14.60671435
> git checkout pristine-tar
> git reset --hard HEAD^ # repeat until at something asterisk_22.1.0*
> git checkout debian/latest
> git reset --hard debian/1%20.0.1_dfsg+_cs6.12.40431414-1
> git tag -d debian/1%22.1.1_dfsg+_cs6.14.60671435-1
> git tag -d upstream/22.1.1_dfsg+_cs6.14.60671435
> tig --all # check that all is gone as intended
> ```
>
> (I commonly use `git reset --hard HEAD^` a lot, because that's easier
> to fetch from my shell history than copy-pasting the specific tags).
>
> Hope that helps.
>
> You might also find help at https://wiki.debian.org/PackagingWithGit
> and some of the resources linked from there.

Thanks very much for your detailed instructions for updating Asterisk in
unstable!

Can we also update the version of Asterisk in trixie to be the same
version as the one in sid, since apparently the one CVE that is blocking
Asterisk in trixie is fixed in sid?  Is there a reason why we would not do
this?

See:

https://security-tracker.debian.org/tracker/source-package/asterisk

Once we do this, then is there any reason (apart from the underspecified
requirement of a credible promise to maintain to a certain standard) for
why Asterisk could not be brought back into trixie?

best regards

FT