Created attachment 228002 [details] databases/keydb shar archive New port - databases/keydb. Upstream: https://github.com/EQ-Alpha/KeyDB What is all about: keydb is an SMP-enabled redis fork (we use it on Linux in a production environment, I want to use it on FreeBSD as well). portlint sequence: ===Cut=== [root@dev:ports/databases]# portlint -ACN /usr/ports/databases/keydb WARN: Makefile: possible use of absolute pathname "/var/db/keydb". WARN: Makefile: possible use of absolute pathname "/var/run/keydb". WARN: Makefile: possible use of absolute pathname "/var/log/keydb". WARN: Makefile: use of DISTFILES with single file discouraged. distribution filename should be set by DISTNAME and EXTRACT_SUFX. WARN: Makefile: DISTFILES/DISTNAME affects WRKSRC. take caution when changing them. WARN: Consider to set DEVELOPER=yes in /etc/make.conf 0 fatal errors and 6 warnings found. ===Cut===
Review items: - Use USE_GITHUB for fetching tagged source code archives for distribution files. MASTER_SITES / DISTFILES / WRKSRC should then not be necessary - += not required for USES (=) - Group and Sort USES/USE_* - TEST_TARGET=test should just work and not require a do-test (invoking GMAKE automatically) - Does this conflict with any redis or redis related? Are CONFLICTS_* required, either for build, or install? If you could also confirm this port passes QA (poudriere), that would be great. Logs are not necessary (set DEVELOPER=yes in /etc/make.conf for extra sanity checks)
Created attachment 230081 [details] databases/keydb shar archive, updated Added the updated port for 6.2.1, with all of the issues mentioned fixed.
Added updated port shar. Fixed all of the mentioned issues. Bumped the port version from upstream to 6.2.1. As about the databases/redis - the binary installation itself doesn't conflict with redis. However, redis and keydb use the same port tcp/6379 when launched - don't know if this is worth CONFLICTING. www/nginx and www/apache24 don't CONFLICT considering the same port situation.
@Reporter (Eugene) Can you review attachment 230081 [details], as you are set as MAINTAINER, or alternatively, liaise with creator of attachment to determine/accept an alternate maintainer
Created attachment 234936 [details] Review previous submission, update to 6.3.1, ran portlint - Added keydb:keydb to UIDs/GIDs files. - Move GH_ACCOUNT from EQ-Alpha to Snapchat, as they have acquired KeyDB - Made TLS a default option, as nothing really should be over plaintext anymore. - removed WRKSRC - update to 6.3.1, make makesum to update distinfo - update patch-src_Makefile for 6.2.1 to 6.3.1 changes - added patch-src_replication.cpp (via make makepatch ) - pkg-plist etc/newsyslog.conf.d/keydb.conf via @sample, because log files should be rotated.
Created attachment 234937 [details] Update MAINTAINER to myself If creating the new port is dependent/blocked on the MAINTAINER being responsive, then I'll take the MAINTAINER role. Eugene is more than welcome to take it back without the need to contact me. ( This is ontop of previous patch/diff. )
I totally don't understand why should I bother about this: the discussion has stalled; the amount of requests to "improve" the port submitted relies entirely to the person commiting/reviewing, from "none, do you want me to commit this or not ?" (yup, I have some buddies port-commiters) to "okay, now you need to test whether this runs fine on NanoBSD mfsbd distribution". This was mainly an experiment to determine whether one can really propose to add new port without engaging his FreeBSD community connections; seems like one can not. BTW significant part of the currently maintained ports (nah, I won't point out) don't meet criterias this port has met. THis (and the port, yup) workd for me, so anyone willing to revive this endless quest should merely resubmit.
I apologize that we haven't been able to address this in a timely manner. There are no requirements to test ports on anything else than FreeBSD (including "variants" such as mfsBSD etc) however it speeds up the process if you mention on what version(s) you've used and platform (i386, amd64, aarch64) both working and non working. It also helps (speeds up the process) if you're able to at least do one build test using Poudriere. As long as someone is willing to maintain keydb I'll have a closer look (there are a few things that needs to get changed/updated) but it looks good overall otherwise I'll close it again.
What needs to be done exactly in order for this port to appear in the ports tree?
At least someone who's willing to become maintainer
(In reply to Dmitry Petrov from comment #9) I need a porters commit bit. :) I'll reach out to someone else I know about this. I also got this update to 6.3.3, and running in a production environment - backing a website that does 50-100k/req/day (unsure on the keydb load). I had to back off mutli-master and active-active, as it had issues in under production load.
Is there a chance for a progress anytime soon? Can someone else with commit bit approve/commit it?
Any chance?
Please submit a patch for 6.3.3 and I'll have a look
Created attachment 245679 [details] Patch to create KeyDB v6.3.3 port Here is a consolidated patch for v6.3.3. Please let me know if anything needs to be tweaked.
Should be removed +# Created by: Eugene M. Zheganin, <eugene@zhegam.in> Switch order and use DISTVERSION https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github +PORTVERSION= 6.3.3 +DISTVERSIONPREFIX= v LIB_DEPENDS should list each entry one a separate line I suspect there might be some ordering issues too, please check using portclippy from ports-mgmt/portfmt Instead of adding -I/usr/local/include , try using USES= localbase or localbase:ldflags . Do note that it might not be needed at all. This also applies to FINAL_LIBS+=-L /usr/local/lib -luuid Source: databases/keydb/files/patch-src_Makefile Does it pass Poudriere? If so what arch and version did you test?
Hit save button too soon... Needed? .include <bsd.port.pre.mk> Thanks for having a look at this and sorry for the late reply!
As I was about to submit a comsolidated patch for the port, I noticed that it is already in the tree. Very odd. https://www.freshports.org/databases/keydb/
The currently committed version (see bug #274745) has some additional patches to modify some compiler/linker flags, but it also removes rocksdb support (note, it requires bash and perl5 at build stage). It also lacks some of the clean ups that your proposed. Please advise.
I'll assign this to Ryan as he's the maintainer of the committed port. You can perhaps try to merge the remaining changes?
Version 6.3.4 of keydb is in ports. Is there an issue with the port or can we safely close this?