pkgsrc-Users archive

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

Re: graphics/vtk & vtk-data 5.10.1

Ray Phillips <> 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

  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

Home | Main Index | Thread Index | Old Index