Created attachment 211417 [details] xiphos new port Tested successfully with poudriere on {11.3,12.1}-RELEASE {i386,amd64}. Bugzilla suggests the port already existed long time ago, although Freshports does not list it. The patch I have submitted has been created from scratch, I have not seen the old port: in fact I have just discovered its existence. -------------------------------- Xiphos is a Bible study application for Linux, UNIX, and Windows operating systems. It uses Sword to display Bibles, commentaries, dictionary, and other texts and images. Xiphos includes features such as, searching, biblesync, bookmarks, parallel study, and original language study. WWW: http://xiphos.org --------------------------------
I add that this bug depends on bug #243916 because xiphos needs byblesync as dependency, which is not yet in the ports tree but I provide as new port through that PR.
One more thing that I should have noted: the Makefile tracks a git commit because last official release depends on python 2.7, which is not supported any more.
One way to find out about expired ports (i.e., ones formerly in the tree and now gone) is the MOVED file: % grep xiphos $PORTSDIR/MOVED misc/gnomesword|misc/xiphos|2009-02-02|Project renamed misc/xiphos||2019-03-24|Has expired: webkit-gtk* last release in 2016 and security issues In such a case we usually "resurrect" a port, see https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ports.html#ports-qa-resurrect
(In reply to Gerald Pfeifer from comment #3) Thanks for the suggestion, I will remember. I hope it is not a problem if I recreated the port from scratch this time. Should I do anything about it?
(In reply to Lorenzo Salvadore from comment #4) > I hope it is not a problem if I recreated the port from scratch this time. > Should I do anything about it? Can you have a look and see how similar the two versions are? And how much you could reuse? In general resurrection is preferable.
(In reply to Gerald Pfeifer from comment #5) Thanks for your reply. I will correct my patch as soon as possible.
Created attachment 211570 [details] xiphos resurrect Patch changed following the instructions for resurrecting ports. The new patch is almost identical to the old one: the port changed much due to the switch of the build system from waf to cmake and from webkit-3 to webkit2-gtk3.
I propose the following commit log message: Resurrect, update and adopt misc/xiphos Resurrect the port and update it from 3.1.6 to a git commit after last release (4.1.0). The commit was selected so that the port does not depend on python 2.7. Resurrection is possible because the dependency on webkit-gtk3 in the expired version has been replaced by a dependency on webkit2-gtk3.
(In reply to Lorenzo Salvadore from comment #8) > Resurrect the port and update it from 3.1.6 to a git commit after last > release (4.1.0) I assume this should be "after the latest release"? (This adds "the", and "last" would imply the project has ended and there are no further releases to be expected.) Why is USE_GCC=yes necessary? This is usually not a good sign for a new port. We'd usually put USE_GNOME directly (or shortly) after USES to keep all those together in one block. No comma in "such as, searching" in pkg-plist. And I'd omit "for Linux, UNIX, and Windows operating systems" which is not very material in this context I think (but that is a recommendation, feel free to decide otherwise). Make sure to include PR: ... in the Approved by: ... when you commit ;-)
(In reply to Gerald Pfeifer from comment #9) If I remember correctly USE_GCC is necessary for avoiding linking problems with byblesync: I could not find any other way to have the linker find biblesync symbols, although I did try! It might be because biblesync needs gcc as well, see https://github.com/karlkleinpaste/biblesync/issues/11 . If you have a better solution I would be glad to implement it. I put USE_GNOME there with the idea that all USE_* variables should be right after USES, together with their related variables. Indeed under USES I have in order USE_GCC, USE_GITHUB and its related variables, USE_GNOME. This makes sense to me and portlint -AC, portclippy and portfmt all like it (and maybe even suggested me to do so). Extra comma removed. I prefer to keep the list of operating systems in pkg-descr: for some people it could be useful to know that the software they are about to install can work on other systems (it answers to question such as "will it work on my job computer? will it work on my friend computer so that we can work together?"). Tell me if you are fine with USE_GCC and USE_GNOME and if you are I will proceed with the commit.
(In reply to Lorenzo Salvadore from comment #10) > If I remember correctly USE_GCC is necessary for avoiding linking problems with > byblesync: I could not find any other way to have the linker find biblesync > symbols, although I did try! It might be because biblesync needs gcc as well, > see https://github.com/karlkleinpaste/biblesync/issues/11 . Ah, I see. Yes, when dependencies are built using GCC that tends to imply the same requirement for the port using those. In this case I suggest adding a comment regarding this. > I put USE_GNOME there with the idea that all USE_* variables should be right > after USES, together with their related variables. Indeed under USES I have > in order USE_GCC, USE_GITHUB and its related variables, USE_GNOME. This makes > sense to me and portlint -AC, portclippy and portfmt all like it (and maybe > even suggested me to do so). I am a bit surprised none of the tools warned about this. Usually we put the USES and USE_* in one block (and the GH_* variable directly after USE_GITHUB there; something like the following: +USES= cmake gettext gnome pkgconfig +USE_GNOME= cairo gconf2 gtk30 gtkhtml4 intltool libgsf +USE_GCC= yes +USE_GITHUB= yes +GH_ACCOUNT= crosswire +GH_TAGNAME= 9e57333 There's flexibility and personal preferences there, but putting each of these in their own block is unusual, so I'd put at least the first three together and then maybe the Github-relates ones in their own block if you prefer.
Oh, and thanks - this looks fine with the feedback above considered.
(In reply to Gerald Pfeifer from comment #11) I added the comment for gcc, but I still have to discuss about the USE block. From the porter handbook, https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#porting-order-uses : "Start this section with defining USES, and then possible USE_x. Keep related variables close together. For example, if using USE_GITHUB, always put the GH_* variables right after it." I can remove the blank lines and I will do, but I cannot put the USE_* variables all together because the GH_* variables must go together with USE_GITHUB and INSTALLS_ICONS with USE_GNOME. I then propose to use the following block: +USES= cmake gettext gnome pkgconfig +#gcc is needed because misc/biblesync is built with gcc +USE_GCC= yes +USE_GNOME= cairo gconf2 gtk30 gtkhtml4 intltool libgsf +INSTALLS_ICONS= yes +USE_GITHUB= yes +GH_ACCOUNT= crosswire +GH_TAGNAME= 9e57333 If this is not acceptable, then we need to correct the porter handbook.
(In reply to Lorenzo Salvadore from comment #13) > I added the comment for gcc, but I still have to discuss about the USE block. Apologies, I was not clear in my previous note. What you propose is perfectly fine (and what I actually had in mind). Personally I would write USE_GCC= yes # misc/biblesync is built with GCC. but you know I'm in for more full stops than others ;-), and you are the maintainer of this port so your style preference matters more. (We usually leave a space after the # and the name of the project is GCC; those are the two changes I'd prefer to see.) Please go ahead and commit including the appropriate PR: and Approved by:; thank you!
A commit references this bug: Author: salvadore Date: Sun Mar 1 12:47:30 UTC 2020 New revision: 527549 URL: https://svnweb.freebsd.org/changeset/ports/527549 Log: Resurrect, update and adopt misc/xiphos Resurrect the port and update it from 3.1.6 to a git commit after the latest release. The commit was selected so that the port does not depend on python2.7. Resurrection is possible because the dependency on webkit-gtk3 in the expired version has been replaced by a dependency on webkit2-gtk3. PR: 243934 Approved by: gerald (mentor) Changes: head/MOVED head/misc/Makefile head/misc/xiphos/ head/misc/xiphos/Makefile head/misc/xiphos/distinfo head/misc/xiphos/pkg-descr head/misc/xiphos/pkg-plist
Committed.