pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Removing editors/hnb "Hierarchical NoteBook"
On Wed, Nov 21, 2018 at 11:46 PM <coypu%sdf.org@localhost> wrote:
>
> Thanks.
>
> 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.
>
This would be a little practice for me to use the commit system, so I
am more than happy to integrate it myself.
>
> 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
> higher.
>
Since the patch spans most of the files used by hnb, I was thinking an
unified diff that covers all the changed files would make more sense
than having to have a new patch-* for every single file changed which
would be close to 35 files.
Do you think a single unified diff with a meaningful file name like
patch-pointer-fixes would make more sense?
> 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
>
Yup, will run it through a pkglint(1) and try to clean up any errors /
warning it reports.
> 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:
> PREFIX?=/usr/local
>
> Most people do not like /usr/pkg, that's just us, but ?= allows it to be
> overwritten.
>
Understood, will make sure these conditions hold up when modifying the
files at editors/hnb
>
> @@ -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 :-)
>
Agreed, I may need to fine tune some of the more ugly things like
"long long int" with "uint64_t"
I shall send you the diff once I have better integration with pkgsrc.
--
Santhosh
Home |
Main Index |
Thread Index |
Old Index