pkgsrc-Users archive

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

Re: Removing editors/hnb "Hierarchical NoteBook"


If you are interested in integrating it yourself, I can guide
you through it and fix any errors you make.
Feel free to send me cvs diffs with 'cvs diff -Nu > ~/hnb.patch' to
review, if it feels wrong.
If you aren't interested then shoutout and I will commit it.

The easy way to create a patch for pkgsrc:
  Install pkgtools/pkgvi
  Set EDITOR to your favourite editor, if you haven't already.
  pkgvi work/hnb*/path/to/file.c			# create .orig
  mkpatches						# diffs .orig and creates patches/patch-*
  make mps						# adjusts "distinfo"

This creates files in patches/patch-*.c based on looking for
.orig files.

Since you already have a patch, you can apply it with patch -p1, and
mkpatches will still do the right thing.

We like to note in the first few lines of patches/patch* why the patch
exists.  cvs log exists, but this patch description is visible to users
too, and won't be hard to find if someone makes a copy of a package, too.

CVS requires new files to be added manually, so e.g.
cvs add patches/patch-path_to_file.c

cvs commit

On a functional commit like this, we will change PKGREVISION to be one

Afterwards, run 'make cce'. If you don't have PKG_DEVELOPER=yes in
/etc/mk.conf, it does nothing. Have it, it enables extra checks.
This will commit a change to doc/CHANGES-2018 and possibly doc/TODO.
We do this whenever PKGREVISION is changed, or the package is updated.

Other things worth doing, but not necessary
- Getting pkgtools/pkglint, and running "pkglint -Wall -Call".
- Doing a clean build after adding patches, so all patches are recorded
- cvs diff -Nu and manually inspecting that no unexpected changes
happened, and all files were 'cvs add'ed, or else they show up as
? patches/patch-path_to_file.c

Diff comments:

We try to create upstreamable diffs where possible.

(1) Since calling GNU make 'gmake' is specific to us and not done in most
linux distros, we try to avoid it.
makefiles usually have MAKE defined to point to the right thing, so we
will make a change like:
-       (cd src;make clean)
-       (cd util;make clean)
+       (cd src;${MAKE} clean)
+       (cd util;${MAKE} clean)

This doesn't matter in pkgsrc, because we install work/.tools/bin/make
to mean 'GNU make' and we amend PATH.

(2) /usr/pkg
+LIBS=-Wl,-R/usr/pkg/lib -lncurses libcli/libcli.a
+CFLAGS=-I.. -Ilibcli -DHAVE_CONFIG_H -Wall -pedantic -g -I/usr/pkg/include -I/usr/include -L/usr/pkg/lib

We try to use ${PREFIX}/include, ${PREFIX}/lib.
If PREFIX is not already defined somewhere (e.g. toplevel makefile),
we can add:

Most people do not like /usr/pkg, that's just us, but ?= allows it to be

@@ -32,7 +32,7 @@ static char address[1024]="";*/
 static char web_command[255] = "galeon -n *";
 static char mail_command[255] = "rxvt -rv +sb -e mutt *";

-static int cmd_system(int argc, char **argv, void *data){
+static long long int cmd_system(int argc, char **argv, void *data){
        Node *pos=(Node *)data;
        int ui_was_inited = ui_inited;
        if (argc>1) {
@@ -42,7 +42,7 @@ static int cmd_system(int argc, char **argv, void *data){
                if (ui_was_inited)
                        ui_init ();
-       return (int)pos;
+       return PTR_TO_UINT64(pos);
 static int action_node (Node *node)

I suspect the right thing is to carry on with void* if possible, but
we're not very picky with last-release-in-2003 editors :-)

Home | Main Index | Thread Index | Old Index