tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [PATCH] ham/chirp update

On Sat, 11 Jul 2020 at 14:53, Greg Troxel <> wrote:
> Paul Ripke <> writes:
> > Just been mucking with some radios and CHIRP, and noticed our pkgsrc
> > version is rather old. Attached patch bumps it to the latest
> > chirp-daily. Not sure if I got everything right, but I've managed
> > to program a couple of radios successfully.
> As a rule pkgsrc packages releases.  I realize that some upstreams are
> broken in that they don't make releases even when they tell everyone not
> to use the release because it is too old.  So we are not 100% on don't
> do that.  But it would be nice to have an upstream bug about not having
> a release to point to.  (This is just an example of the general
> principle in pkgsrc that upstream problems should be fixed upstream, and
> if we have workarounds, we should be clear and readers of the pkgsrc
> bits should be clear that what we have is a workaround for upstream
> problems.)
> I am in general much more comfortable having a 2nd package that is
> tracking the latest development branch, than updating the main one.  But
> in this case that may be tilting at windmills.
> We often call these things -devel, to say what they are semantically, vs
> how we get them (daily snapshots, git, svn, etc.).
> Are you willing to add this to wip?  It is much easier for me to deal
> with updates/new pacakges in wip, because it skips the
> unpacking/etc. step and multiple people can make tweaks.
> Info at
> and to get commit privs all you need to do is mail an ssh key as
> described in the link.

What you say makes sense in principle, but in the case of chirp,
upstream have decided they are going to release their packages as
chirp-daily. I think the OP's approach probably makes more sense.


"you do not need to worry about finding a stable version to run. You
should always be on the latest build available."

Ottavio Caruso

Home | Main Index | Thread Index | Old Index