Re: How to best submit fixes to pkgsrc

[Carsten Strotmann <carsten%strotmann.de@localhost>]

Hi Greg,

thanks for your answer. My comments below

On Thu, 30 Dec 2021 14:12:16 +0100,
Greg Troxel wrote:
> 
> [1  <text/plain (quoted-printable)>]
> 
> Carsten Strotmann <carsten%strotmann.de@localhost> writes:
> 
> > I'm rebuilding my pkgsrc setup on Solaris 9, MacOS 10.4 and MacOS 10.9
> > during the last days and I found a couple of issues (and
> > workarounds/fixes).
> 
> I'm unclear on Solaris versions but am guessing that pkgsrc Solaris
> people might consider 9 new enough to be acceptable for bug reports.
> 
> On Mac, 10.4 and 10.9 are ancient, and I realize you know this :-) See
> bootstrap/README.macOS:
> 
>   Because Apple drops support for previous hardware faster than the
>   hardware fails, many machines cannot be upgraded to recent versions of
>   macOS, creating a greater than usual desire to support old systems.
> 
> 
> A side note is that some people run NetBSD on old Mac hardware.  For
> example, I am currently using a MacBookPro from 2008 and a MacBook from
> 2006 as pkgsrc build machines.  I'm not saying you *should* do this,
> just pointing out that it's a way to use old hardware without old
> software.

Yes, I'm aware of this and I run some older machines with NetBSD and
OpenBSD, and that is a fine solution.

But I also have some machines where I want to keep certain command
line tools "recent" (ssh, git, vim, python/ruby/lua, emacs(en), gcc, forth).

This is definatly "retrocomputing", I don't use these machines "in
production", but I sometimes do software development on these old
machines.

> 
> > What is the best way to report these issues/workarounds/fixes to the
> > pkgsrc project?
> 
> First, the question is whether the problem is in the upstream tarball
> 
>   * If when you unpack the upstream tarball and build it using their
>     instructions it fails to build, fix the problem there and submit it
>     to upstream.  Then you can add patches to pkgsrc, making it
>     effectively like upstream released a micro with those changes.
> 
>   * If upstream does build, but the package doesn't, then you've
>     found a packaging bug.  You can fix the package.
> 
> Once you have package changes, there are basically four paths:
> 
>   * Submit a PR (send-pr on NetBSD, and presumably in pkgsrc).
> 
>   * Mail a patch that fixes the issue, along with a commit message, here.
> 
>   * Same, but figure out which pkgsrc developer takes care of the
>     package by checking MAINTAINER or commit history.
> 
>   * Put a version of the package that works in pkgsrc-wip, which doesn't
>     require meeting pkgsrc standards and where commit access is handed
>     out pretty much just for asking:
>       http://pkgsrc.org/wip/
>     and then when the package in wip works, ping here or someone you
>     think cares about the package.
> 
> Comments:
> 
>   Bug reports without fixes for 10.4 and 10.9 don't belong in the bug
>   tracker.  Sorry, but nobody is going to pay attention and it's just
>   clutter.  Even with fixes, it's getting iffy.  It's starting to feel
>   like 10.13 is retrocomputing, even though there's hardware that's
>   totally ok and beefy enough to be usable (e.g. 16G RAM, big SSD).  The
>   only 10.11 machine I know of is unusable due to having only 2G of
>   RAM.

I will only post patches/fixes where the fix is straightforward and
does not create issues for modern platforms (modern machines should
always be the priority).

>   
>   Patches to accomodate old systems can be added if they are clean,
>   meaning they don't cause significant additional cognitive load, or any
>   negatives for users of maintained operating systems.
> 
>   If changes to pkgsrc result in adding a patch (to the upstream
>   distfile), pkgsrc norms require that to have an explanatory comment
>   and that the change be filed with upstream and a reference put in the
>   patch file, or an explanation that there is no functioning upstream.
>   While this (documented) norm is fairly rough in pkgsrc, I'm not
>   inclined to bend from it when accomodating old systms.
>

ACK, will do that.

> 
> Beyond that, you are welcome to ask for help in working on this.  Do
> read the guide (doc/pkgsrc.txt) through all the way first.  pkgsrc has a
> tradition of helping new people in the hopes that we can talk them into
> further contributions.


Thanks for your work on pkgsrc and helping out.

best wishes for a good new year 2022!

Carsten