Ray Phillips <r.phillips%uq.edu.au@localhost> writes: >>To make this easier in the future: >> >>Each patch should have a comment explaining what it's doing and why, and >>giving status of whether it has been sent upstream or not, and the >>upstream bug tracker URL. When patches are merged upstream, pkgsrc >>updates are far easier. > > I don't follow "whether it has been sent upstream" but suppose I would > if I'd created a package and had it absorbed into the packages > collection. What I meant is that the norm (not entirely followed) for pkgsrc patches is: add patch to fix some issue include comment that explains what the issue is if the fix belongs upstream, send it upstream and note the upstream bugtracker URL, if the project is mature enough to have a bugtracker, or a mailinglist archive URL, or whatever you can manage if the fix doesn't belong upstream, make sure the comment explains why it's not appropriate. typically this is for changes to example directories to conform to pkgsrc. Anything that would be needed by someone compiling outside of pkgsrc belongs upstream. > I have now applied the NetBSD patches for vtk 4.2 that were applicable > to 5.10.1 and attempted to compile it again. It went further than > before, judging by the percentage figure displayed and the time it > took for make to stop, but curiously it stopped with the same > error--see below. > > I guess I'll just have to try to get to grips with the source code, or > even resort to using Linux. It's helpful to do this kind of work in pkgsrc-wip (on sourceforge), because then others can have access to your partial work and help. If you would like write access to pkgsrc-wip just privately email me your sourceforge username.
Attachment:
pgpl4Q8H4745F.pgp
Description: PGP signature