Created attachment 214090 [details]
svn diff to fix MASTER_SITES
This port is currently marked BROKEN for lack of a
working MASTER_SITES. This pr(1) fixes that.
I use this port. So felt compelled to fix it.
That's it. Thanks!
This is an abandonware, we do not need this in the ports tree.
Hi, Chris, and thank you for your help. I apologize for antoine@ abruptness -- and factually-incorrect statement, and will look into means of recovering the port soon.
The tarball are still downloadable -- via FTP -- from the original site using a browser (such as Firefox), but our fetch(1) fails. Something is wrong with the upstream's server, that needs investigating.
Would you like to be made the port's maintainer?
(In reply to Mikhail Teterin from comment #2)
As to "abandonware". That statement can hardly be true
if someone, anyone wants to continue to use/maintain it.
We use this at work (since we use a lot of Tcl on FreeBSD) in a Jenkins job.
While you could reasonably argue the original author has abandoned it, the tool is still very useful and produces superior error messages to Tcl for things like missing braces and the like.
We could host the distfile at work as well if that would help.
(In reply to darius from comment #4)
I've spoken with the author offline, and he indicates
that the fact that it was actually available in the
first place was a bit of a fluke. But was happy to take
advantage of it as long as it lasted. I won't have any
trouble hosting the source, as I've been doing for other
ports I maintain for some 10yrs. But if you'd like to
provide an additional link. That would be great.
Thanks for piping up.
Created attachment 214862 [details]
Eliminate compiler warnings - and fix some errors
Gentlemen, please, try using frink with this patch dropped into files/ directory.
If we are to restore the port, may as well ensure clean compilation... Thank you!
(In reply to Mikhail Teterin from comment #6)
Thanks, that fixes most warnings but I still get..
make: "/usr/share/mk/bsd.opts.mk" line 101: warning: "NO_MAN is defined, but deprecated. Please use MK_MAN=no instead."
vars.c:202:32: warning: implicitly declaring library function 'malloc' with type 'void *(unsigned long)' [-Wimplicit-function-declaration]
VarData *blp = (VarData *) malloc(sizeof(VarData));
vars.c:202:32: note: include the header <stdlib.h> or explicitly provide a declaration for 'malloc'
1 warning generated.
Both are fixed by replacing files/Makefile.bsd with the attached version.
Created attachment 214863 [details]
(In reply to darius from comment #7)
> make: "/usr/share/mk/bsd.opts.mk" line 101: warning: "NO_MAN is defined, but deprecated. Please use MK_MAN=no instead."
That's a warning from make -- not compiler. I'm hesitant to use MK_MAN, because I remember it not working with earlier FreeBSD-releases...
> Both are fixed by replacing files/Makefile.bsd with the attached version.
Yes, thank you, I also define HAVE_STDLIB here -- and set WARNS=7 -- but my request was to test the resulting executable for regressions...
Does the program still work for you after patching? The author has no self-test suit, and I ran it on a couple of .tcl scripts here -- but I don't regularly use it, so I'm asking for testing.
(In reply to Mikhail Teterin from comment #9)
Yes, it does work and produces the same output - sorry I didn't mention that earlier.
For MK_MAN - I don't think any supported version of FreeBSD would choke on it.
Created attachment 214895 [details]
build output after applying Mikhail's diff
Well for what it's worth I chopped your diff up
into proper port patch files, and found I needed to
replace NO_MAN with MK_MAN= no.
The file attached is a build run on the port. Warnings
still exist. But the port seems to work as intended. If
the warnings left are considered acceptable. I'll whip
up a proper svn diff and attach it.
P.S. MK_MAN= no is supported on 11. So it's fine.
Created attachment 214931 [details]
svn diff for devel/frink based on current work, and input from others involved here
OK here's an svn diff based on work I've done, as well as
current work, and comments in this pr.
I'm also including the output of a build run based on the same.
The errors emitted are simply caused by function names
having not been declared before use/call. But otherwise have
no ill affect on run/use.
Created attachment 214932 [details]
build run against most recent svn diff I submitted
Here's the output of the build run against the
svn diff (patch) I just submitted.
> frink.c:800:5: warning: implicit declaration of function 'flushOutput' is invalid in C99 [-Wimplicit-function-declaration]
Strange, I do not see these here -- neither on 11.3, nor on 12.1...
> I chopped your diff up into proper port patch files
portlint, kind of, twists your arm into doing that, but I resist -- because I prefer to group patches together by the problems they mean to address.
Anyway, committing the thing now -- have to restore it from the Attic first :(
A commit references this bug:
Date: Mon Jun 1 01:26:27 UTC 2020
New revision: 537453
Restore devel/frink. Hand over the maintainership to the PR-submitter.
Fix compiler warnings.
Submitted by: Chris Hutchinson
Thank you very much for all the time, and work
you put into this! :-)
(In reply to commit-hook from comment #15)
Why wasn't my patch (svn diff) applied?
The latest patch I submitted should have been
the one used to update this port. But clearly
===> Building for frink-2.2.2p4_1
make: "/usr/share/mk/bsd.opts.mk" line 102: "NO_MAN is defined, but deprecated. Please use MK_MAN=no instead."
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
*** Error code 1
Taking a look at the freebsd svn tree also
confirms that my proposed changes were not applied.
Please apply my latest provided svn diff so this
port works, and builds properly.
Created attachment 215258 [details]
patch: pets pkg-fallout, adds LICENSE
OK while the patch committed violates the ports
framework etiquette. It's tidier, and gets the
job done. BUT it omitted some things, and prevents
the port from building.
The patch I'm attaching to this pr fixes them;
NO_MAN= regretfully ==> MK_MAN= no
^Triage: Assign to committer resolving/resolved (comment 15)
^Triage: Re-open. Chris
@Mikhail Chris (maintainer) has submitted a new patch to fix the build issue
*** Bug 247101 has been marked as a duplicate of this bug. ***
(In reply to Chris Hutchinson from comment #18)
> OK while the patch committed violates the ports framework etiquette.
I don't believe, etiquette prescribes one approach over another...
> It's tidier, and gets the job done.
> BUT it omitted some things, and prevents the port from building.
This part puzzles me... Though a compiler warning may cause the build to fail (depending on one's -Werror setting), a make warning should not...
Indeed, these two exist already:
I cannot find the package for 13 -- is that the release, which turns a make-warning into an error?..
As for the patch, do you think, a PORTREVISION bump is warranted over something so trivial as an explicit license-declaration?
I indicated in comment #11 that MK_MAN=(yes|no) was
required, and is also supported in 11. But somehow
it got lost. :-)
Anyway; Because it wasn't included, the port will no
[package - head-i386-default][devel/frink] Failed for frink-2.2.2p4_1 in build
Log URL: http://beefy17.nyi.freebsd.org/data/head-i386-default/p538136_s361880/logs/frink-2.2.2p4_1.log
Build URL: http://beefy17.nyi.freebsd.org/build.html?mastername=head-i386-default&build=p538136_s361880
[package - head-amd64-default][devel/frink] Failed for frink-2.2.2p4_1 in build
Log URL: http://beefy18.nyi.freebsd.org/data/head-amd64-default/p538136_s361880/logs/frink-2.2.2p4_1.log
Build URL: http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p538136_s361880
The final (most recent) patch I provided here, will:
1) fix MK_MAN entry
2) add the required LICENSE stanza(s)
and the ports framework will once again smile upon this port. :-)
(In reply to Chris Hutchinson from comment #23)
> The final (most recent) patch I provided here, will:
> 1) fix MK_MAN entry
> 2) add the required LICENSE stanza(s)
It will also bump PORTREVISION, forcing people to rebuild, and mirrors -- to host another copy. Do you think the 2) warrants the revision bump?
> It will also bump PORTREVISION,
Crap! I forgot to mention that. Sorry. :-(
> forcing people to rebuild, and mirrors -- to host another copy. Do you think > the 2) warrants the revision bump?
My rational on that, is that if it isn't working as
has been committed. The package builders should get
a hint that the (port)revision has been updated to
create a *working* version.
If I am wrong in this regard. Please feel free to
correct that. :-)
Created attachment 215383 [details]
patch for devel/frink; pets pkg-fallout, adds LICENSE, no PORTREVISION bump
Same patch as last one. But without PORTREVISION bump
in case that is the preferred route. :-)
A commit references this bug:
Date: Wed Jun 10 03:29:46 UTC 2020
New revision: 538365
Fix build on HEAD, where the NO_MAN-knob is no longer valid. Add
Submitted by: Chris Hutchinson
Committed, thanks! I had to swap around the last two LICENSE-lines, because portlint was complaining about them being "out of order".
(In reply to Mikhail Teterin from comment #28)
Thanks, Mikhail! :-)