Created attachment 218657 [details] Shar of new port "www/castor" Castor is an actively developed graphical browser for text-based protocols written in Rust that uses the GTK+ toolkit. It currently supports the Gemini, Gopher and Finger protocols. Gemini is a modern take on creating a text-based protocol that lives up to today's standards technically (e.g. it uses TLS). It aims to provide a "middle ground" between the bare-bones Gopher and the bloated WWW but leaning towards the former. ----- The port builds and passes "synth test www/castor" without any findings. Portlint is happy, too, except for the definition of DISTFILES. The latter is necessary, however, since otherwise the main distfile gets discarded. Solution proposed by kevans (thanks again!).
Just an FYI (no need for action on this here, I'm OK with shar), we do recommend these days just uploading a diff even for new ports rather than bothering with shar. The PHB recommends svn-diff[0], but I don't know anyone that would complain if you provide a git-diff instead. =) [0] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-submitting.html
A `poudriere testport` offered the following complaints: > Using USE_GNOME alone is deprecated, please add USES=gnome. > Error: /usr/local/bin/castor is linked to /usr/local/lib/libcairo-gobject.so.2 from graphics/cairo but it is not declared as a dependency > Warning: you need USE_GNOME+=cairo > Error: /usr/local/bin/castor is linked to /usr/local/lib/libcairo.so.2 from graphics/cairo but it is not declared as a dependency > Warning: you need USE_GNOME+=cairo > Error: /usr/local/bin/castor is linked to /usr/local/lib/libgdk_pixbuf-2.0.so.0 from graphics/gdk-pixbuf2 but it is not declared as a dependency > Warning: you need USE_GNOME+=gdkpixbuf2 I confirmed with [0] that it does formally depend on cairo and gdkpixbuf2, applied the following diff, and I'm re-confirming the build on 11/amd64 and 12/i386: root@viper:/usr/local/poudriere/ports/default/www/castor# diff Makefile.orig Makefile 15,16c15,16 < USES= cargo desktop-file-utils ssl < USE_GNOME= glib20 gtk30 --- > USES= cargo desktop-file-utils gnome ssl > USE_GNOME= cairo gdkpixbuf2 glib20 gtk30 [0] https://git.sr.ht/~julienxx/castor/tree/master/README.md
Ah, ok. So these should be explicitly added, too? Note taken in my head. In general it looks like I should finally make the switch from Synth to Poudrière for working on ports... I'm also curious to see if the patched port works out well on tier1 platforms.
A commit references this bug: Author: kevans Date: Wed Oct 14 23:56:39 UTC 2020 New revision: 552362 URL: https://svnweb.freebsd.org/changeset/ports/552362 Log: [NEW PORT] www/castor: Graphical browser for text-based inet protocols Castor is an actively developed graphical browser for text-based protocols written in Rust that uses the GTK+ toolkit. It currently supports the Gemini, Gopher and Finger protocols. Gemini is a modern take on creating a text-based protocol that lives up to today's standards technically (e.g. it uses TLS). It aims to provide a "middle ground" between the bare-bones Gopher and the bloated WWW but leaning towards the former. PR: 250266 Submitted by: Michael Reim <kraileth elderlinux org> Changes: head/www/Makefile head/www/castor/ head/www/castor/Makefile head/www/castor/distinfo head/www/castor/files/ head/www/castor/files/pkg-message.in head/www/castor/pkg-descr
Committed, thanks!
Thanks for your help of getting this across the finish line! I'm keeping an eye on it and will try to provide updates as the upstream project releases new versions. Newbie question: The best way to hand in patches would be to simply send a message with an attached SVN / Git diff to freebsd-ports@, correct?
(In reply to Michael Reim from comment #6) No problem! For updates, you'll want/need to use Bugzilla for each; subject line indicating www/castor and brief overview like this one does, useful summary in the body, and patch attached. There's perhaps two compellinv reasons: 1. It lets us organize on the PR (with metadata) so it's clear to everyone else what's going on, and 2. There's some automation involved that will build the attached patch and flag it with buildisok, which helps lower the barrier for someone to pick it up
can we close this pr?
Oh yes, the port landed so this should be closed.