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. CHANGES Makefile MASTER_SITES 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) Yes, please. @antoine As to "abandonware". That statement can hardly be true if someone, anyone wants to continue to use/maintain it. Thanks! :-) --Chris
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. --Chris
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[2]: "/usr/share/mk/bsd.opts.mk" line 101: warning: "NO_MAN is defined, but deprecated. Please use MK_MAN=no instead." and.. 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] files/Makefile.bsd
(In reply to darius from comment #7) > make[2]: "/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. Please, advise.
(In reply to Mikhail Teterin from comment #9) Hi Mikhail, 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. --Chris 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. --Chris
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. --Chris
> 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: Author: mi Date: Mon Jun 1 01:26:27 UTC 2020 New revision: 537453 URL: https://svnweb.freebsd.org/changeset/ports/537453 Log: Restore devel/frink. Hand over the maintainership to the PR-submitter. Fix compiler warnings. PR: 246163 Submitted by: Chris Hutchinson Changes: head/devel/Makefile head/devel/frink/ head/devel/frink/Makefile head/devel/frink/files/Makefile.bsd head/devel/frink/files/patch-warnings
@Mikhail Thank you very much for all the time, and work you put into this! :-) --Chris
(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 wasn't. From pkg-fallout@: ===> Building for frink-2.2.2p4_1 make[1]: "/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 the maintainer. *** 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. Thanks. --Chris
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; CHANGES NO_MAN= regretfully ==> MK_MAN= no adds LICENSE That's it. Thanks! :-) --Chris
^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. Thank you. > 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: http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/frink-2.2.2p4_1.txz http://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/frink-2.2.2p4_1.txz 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?
Hello All, 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 longer build: [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. :-) That's it. Thanks! :-) --Chris
(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. :-) Thanks! :-) --Chris
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. :-) --Chris
A commit references this bug: Author: mi Date: Wed Jun 10 03:29:46 UTC 2020 New revision: 538365 URL: https://svnweb.freebsd.org/changeset/ports/538365 Log: Fix build on HEAD, where the NO_MAN-knob is no longer valid. Add license-declaration. PR: 246163 Submitted by: Chris Hutchinson Changes: head/devel/frink/Makefile head/devel/frink/files/Makefile.bsd
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! :-)