Created attachment 255788 [details] Patch for curl * Use GitHub as primary site and curl.se as fallback * Transfer maintainership to desktop@ for more reviewers and more streamlined maintenance in tree (discussed with fluffy) * Switch to CMake, less local patching (upstream is also very active in fixing reported issues), faster and more flexible builds * Try to stay within 78 columns whenever possible in Makefile * Modernize Makefile layout to follow Porters Handbook more closely * Sort options and adress several dependencies (*_IMPLIES) * Add MANPAGES and ZSH options, disabling these will remove Perl build dep * Add STATIC option * Remove BROTLI from ZSTD from DEFAULTS (can of course be added again) * Improve performance of "make test" Compile and runtime tested on FreeBSD 14.1-RELEASE (amd64) (make, make check-plist, make test) Poudriere testport OK 13.3-RELEASE (amd64) Poudriere testport OK 13.4-RELEASE (amd64) Poudriere testport OK 14.1-RELEASE (amd64) Poudriere testport OK 14.2-RELEASE (amd64) Tested with following consumers in Poudriere on 14.1-RELEASE (amd64): Running here: https://pdr2.bofh.network/build.html?mastername=141-diizzy&build=2024-12-11_12h10m06s *** Note *** List is taken from freshports.org (library dependency) archivers/urbackup-server archivers/zchunk astro/cfitsio astro/foxtrotgps astro/gnuastro astro/mepo astro/opencpn astro/phd2 astro/siril astro/viking audio/ardour audio/ario audio/cyanrip audio/deadbeef audio/faustlive audio/grip audio/gtkpod audio/guitarix-lv2 audio/icecast audio/moc audio/mpdas audio/mpdscribble audio/musicpd audio/ncmpcpp audio/osd-lyrics audio/owntone audio/pianobar audio/pianod2 audio/streamtranscoder audio/vimpc audio/vorbis-tools audio/zrythm benchmarks/flowgrind biology/htslib biology/hyphy biology/iolib biology/libbigwig biology/py-pybigwig biology/salmon biology/vcflib biology/vt cad/PrusaSlicer cad/horizon-eda cad/kicad cad/kicad-devel chinese/fcitx-cloudpinyin chinese/fcitx5-chinese-addons chinese/gcin comms/gammu comms/gpredict comms/libconcord comms/sigdigger comms/svxlink comms/trustedqsl comms/xastir converters/bibtexconv databases/mariadb-connector-c databases/mariadb1011-server databases/mariadb114-server databases/mongodb50 databases/mongodb60 databases/mongodb70 databases/mongodb80 databases/mysql80-client databases/mysql80-server databases/mysql84-client databases/mysql84-server databases/mysql90-client databases/mysql90-server databases/postgresql-repmgr databases/recutils databases/spatialite_gui databases/sqlrelay databases/tarantool databases/tarantool2 (broken, see pkg-fallout) databases/tiledb databases/xrootd databases/xtrabackup80 databases/xtrabackup81 (fails, unrelated) PR 283058 databases/xtrabackup84 deskutils/cairo-dock deskutils/cairo-dock-plugins deskutils/cherrytree deskutils/fbreader deskutils/growl-for-linux deskutils/kdepim-runtime deskutils/pinot deskutils/subsurface devel/aegis devel/appstream devel/appstream-glib devel/aws-sdk-cpp devel/cargo-c devel/cargo-generate devel/cargo-udeps devel/cmake-gui devel/date devel/dub devel/efl devel/elfutils devel/gcli devel/git-cinnabar devel/gitaly devel/gitoxide devel/google-cloud-cpp devel/indi devel/juce devel/juce706 devel/kcov devel/kore (broken, see pkg-fallout) devel/leatherman devel/libdap devel/libdatovka devel/libgutenfetch devel/libkiwix devel/libserdes devel/libvirt devel/mm-common devel/opentelemetry-cpp devel/phasar devel/root devel/rudiments devel/sentry-cli devel/simgear devel/smooth devel/wandio devel/wrangler devel/xmltooling dns/dnsdbflex dns/dnsdbq dns/https_dns_proxy dns/powerdns dns/powerdns-recursor editors/imhex editors/imhex-current editors/libreoffice editors/openoffice-4 editors/openoffice-devel emulators/dolphin-emu emulators/emulationstation emulators/es-de emulators/fbsd-duckstation emulators/flycast emulators/libretro-reicast emulators/pcsx2 emulators/qemu emulators/qemu-devel emulators/qemu8 emulators/reicast emulators/rpcs3 emulators/tic-80 emulators/vice emulators/virtualbox-ose emulators/virtualbox-ose-legacy emulators/virtualbox-ose-nox11 emulators/virtualbox-ose-nox11-legacy filesystems/curlftpfs filesystems/httpdirfs filesystems/s3backer filesystems/s3fs finance/ktoblzcheck finance/libofx finance/tickrs ftp/R-cran-RCurl ftp/R-cran-curl ftp/coeurl ftp/curlpp ftp/gstreamer1-plugins-curl ftp/ocaml-ocurl ftp/php81-curl ftp/php82-curl ftp/php83-curl ftp/php84-curl ftp/py-pycurl ftp/rexx-curl ftp/rubygem-curb ftp/wmget games/0ad games/7kaa games/DDNet games/SRB2 games/alephone games/alienarena games/assaultcube games/bzflag games/bzflag-server games/craft games/crossfire-client games/dhewm3 games/doomsday games/enigma games/etlegacy games/evq3 games/ezquake games/f1spirit-remake games/flightgear games/freebee games/freeciv games/freeciv-nox11 games/freeminer games/gnubg games/gtkevemon games/ioquake3 games/iortcw games/kartofel games/keeperrl games/klavaro games/kuklomenos games/lgogdownloader games/luanti games/meandmyshadow games/megaglest games/moonlight-embedded games/moonlight-embedded-devel games/mvdsv games/nexuiz games/openarena games/openlierox games/openrct2 games/openspades games/openttd games/pokerth games/powder-toy games/powder-toy-devel games/quakeforge games/slade games/supertux2 games/supertuxkart games/ufoai games/warmux games/warzone2100 games/wesnoth games/worldofpadman games/xmoto games/xonotic graphics/aseprite graphics/cimg graphics/darktable graphics/feh graphics/filmulator graphics/gdal graphics/gmic graphics/gmic-qt graphics/gmt graphics/gnash graphics/ipe graphics/jp2a graphics/krita-gmic-plugin graphics/libgphoto2 graphics/librasterlite2 graphics/mapserver graphics/mupdf graphics/osgearth graphics/proj graphics/rawstudio graphics/sane-backends graphics/simpleviewer graphics/telak graphics/tesseract irc/iroffer-dinoex irc/weechat lang/algol68g lang/gnustep-base lang/julia lang/rust lang/rust-nightly lang/rust182 mail/claws-mail-fancy mail/claws-mail-libravatar mail/claws-mail-litehtml_viewer mail/claws-mail-managesieve mail/claws-mail-rssyl mail/claws-mail-spam_report mail/claws-mail-vcalendar mail/libetpan mail/milter-greylist mail/nmh mail/nmh-devel math/R math/asymptote math/elan math/giacxcas math/gretl math/libRmath math/libqalculate math/mprime math/octave math/pdal math/saga math/sage math/scilab misc/ignition-fuel-tools misc/iio-oscilloscope misc/librepo misc/sword misc/trurl misc/wmweather+ multimedia/audacious-plugins multimedia/butt multimedia/kodi multimedia/libmediainfo multimedia/mediaelch multimedia/musikcube multimedia/nostt multimedia/nymphcast multimedia/obs-streamfx multimedia/obs-studio multimedia/qmmp-qt5 multimedia/qmmp-qt6 multimedia/tvheadend multimedia/xine net/asterisk18 net/boinc-client net/deviceatlas-enterprise-c net/ecal net/fort net/freeipa-client net/freeswitch net/gerbera net/glusterfs net/grive2 net/kamailio net/libcmis net/libnpupnp net/liboauth net/librdkafka net/mad_fcl net/measurement-kit net/megacmd net/megatools net/ntopng net/onedrive net/opensips31 net/pecl-oauth2 net/remmina net/rubygem-ovirt-engine-sdk net/sakisafecli net/uget net/xmlrpc-c net-im/concord net-im/profanity net-im/snac net-im/toxic net-mgmt/ettercap net-mgmt/nagnu net-mgmt/netxms net-mgmt/sblim-wbemcli net-mgmt/seafile-client net-mgmt/seafile-server net-mgmt/zabbix5-agent net-mgmt/zabbix5-proxy net-mgmt/zabbix5-server net-mgmt/zabbix6-agent net-mgmt/zabbix6-proxy net-mgmt/zabbix6-server net-mgmt/zabbix64-agent net-mgmt/zabbix64-proxy net-mgmt/zabbix64-server net-mgmt/zabbix7-agent net-mgmt/zabbix7-proxy net-mgmt/zabbix7-server net-p2p/clboss net-p2p/cpuminer net-p2p/pulsar-client-cpp net-p2p/retroshare net-p2p/rtorrent net-p2p/transmission-components ports-mgmt/appstream-generator print/foomatic-db-engine print/miktex science/healpix science/lammps science/libkml science/netcdf science/openmodelica science/orthanc science/orthanc-mysql science/py-tensorflow science/qbox security/0d1n security/beid security/cardpeek security/clamav security/clamav-lts security/gnupg1 security/iddawc security/lastpass-cli security/libreswan security/libtatsu security/modsecurity3 security/opensaml security/openvas security/osslsigncode security/rhonabwy security/sssd2 security/strongswan security/tpm2-tools security/tpm2-tss security/uacme security/wazuh-manager security/ykclient shells/sheldon sysutils/abgx360 sysutils/afflib sysutils/amtc sysutils/bacula-libs3 sysutils/barrier sysutils/cbsd sysutils/cfengine sysutils/cfengine-devel sysutils/cfengine-lts sysutils/cfengine321 sysutils/cfengine322 sysutils/cfengine323 sysutils/cfengine324 sysutils/cluster-glue sysutils/createrepo_c sysutils/eclat sysutils/facter sysutils/google-compute-engine-oslogin sysutils/libdnf sysutils/lnav sysutils/mdcat sysutils/nix sysutils/pacman sysutils/passwordsafe sysutils/powerman sysutils/rsyslog8 sysutils/synergy sysutils/syslog-ng sysutils/zellij textproc/libkolabxml textproc/libmrss textproc/libnxml textproc/multimarkdown textproc/py-ucl textproc/raptor2 textproc/zorba www/apache24 www/cas www/castget www/cplanet www/cpr www/davix www/domoticz www/domoticz-devel www/edbrowse www/envoy www/flickcurl www/hurl www/janus www/mod_auth_cas www/mod_auth_mellon www/mod_auth_openidc www/mod_security www/mod_webauth www/netsurf www/newsboat www/newsraft www/onlyoffice-documentserver www/ot-recorder www/p5-Net-Curl (fails to build, not a new issue) see pkg-fallout www/p5-WWW-Curl www/pecl-http www/pecl-solr www/pecl-yar www/rubygem-ethon www/rubygem-passenger www/rubygem-patron www/sogo www/sogo-activesync www/sogo2 www/sogo2-activesync www/trafficserver www/ulfius www/wasm-pack www/wsdlpull x11/hamclock x11/polybar x11-toolkits/wxgtk32 Regarding transfer of maintainership, Po-Chuan has been maintainer for a very long time and put in a lot of time and effort however having a single person as maintainer for a "high profile" port also shows its limitations/bottlenecks as seen in PRs such as 283020, 280653, 269967 and due to circumstances you might not always be available which is why assigning it to a group is likely a better idea for some ports such as this one. This works for me (tm) but please "battle test" it for potential issues.
I'm not in favour of passing maintainership to desktop@: 1) curl is too deep-level port for desktop@; 2) desktop@ is underpowered and has already plethora of ports to care about; 3) from my perspective Po-Chuan does good job maintaining the port: https://www.freshports.org/ftp/curl As for other proposals, the patch combines many changes, which make it hard to review. Could you please split style changes, update and switch to cmake? I believe switching low-level ports like curl to cmake should be discussed more widely, and in case of agreement should be done separately from the update and perhaps after dedicated exp-run only. Cheers, Max
Created attachment 255812 [details] Patch for curl v2 Backport upstream commit ff5091aa9f73802e894b1cbdf24ab84e103200e2 to fix eventfd Reference: https://github.com/curl/curl/commit/ff5091aa9f73802e894b1cbdf24ab84e103200e2
Created attachment 255838 [details] Patch for curl v3 Fix typo
(In reply to Max Brazhnikov from comment #1) Hi, As this Makefile is rather small it creates a lot more work for little win, it's easier if you review both Makefiles side by side by I can point you to specific changes if you have any questions. fwiw, PR 283020 is now past maintainer timeout without any response Best regards, Daniel
I'm generally supportive of these changes. With regards to maintainer ship, while Po-Chuan is doing a good job, I fail to understand how one can argue that an entire group like desktop@ can be under-powered compared to an individual. A look at portsfallout might be worth considering.
The discussion with fluffy@ about the consideration of taking a port away from an active maintainer who is a committer needs to be public, especially since the maintainer was not publicly involved in that discussion. I as a desktop@ member am not comfortable with having this port dumped on us without at least the current maintainer's explicit consent, regardless of timeout. The reason why sunpoet@ has not approved cmake usage previously, and is unlikely to be approved still, is because upstream's build/install documentation does not mention it *anywhere*, let alone the Unix section: https://curl.se/docs/install.html The first step to maybe making cmake palatable is to not only document it as such, but more importantly endorse it over the current documented process for Unix-like platforms which is autotools, officially upstream. Everything else, including any technical arguments, is irrelevant. curl.se is the canonical home of the project and is where the release tarballs live, so it should still be the primary MASTER_SITES. Anything can slip through the cracks regardless of maintainer type, I don't see how dumping this on desktop@ helps things. The current process of suggesting changes to the maintainer works as intended, even if they are not approved and later reverted.
(In reply to Charlie Li from comment #6) You mean the documentation provided by the founder? https://curl.se/ --> Documentation At the top " The book: Everything curl This is a detailed and totally free book, available online (and as a PDF as a link from there) that explains everything there is to know about curl, libcurl and the associated project. Learn how to use curl. How to use libcurl. How to build them from source or perhaps how the curl project accepts contributions. There is something for everyone in this, from the casual first-time users to the experienced libcurl hackers. " Which directs you to https://everything.curl.dev/build/index.html Click on "7. Build curl and libcurl" https://everything.curl.dev/build/cmake.html It's also extensively tested, see https://github.com/curl/curl/pull/15596/checks (for example)
(In reply to Daniel Engberg from comment #7) And the chapter introduction still endorses autotools: > There are two different build environments to cater to people's different opinions and tastes. The configure-based build is arguably the more mature and more encompassing build system and should probably be considered the default one. The rest of the curl website is also official documentation, so the point against cmake still stands. But more importantly, you need to convince the current maintainer, not me.
Why changing maintainer ? do you have his approval and you engage a conversation with him ? I am very skeptical also about the switch to cmake, why is it more flexible I see the claim and I don't see any facts ? The argument about less local patches also stands for autotools, upstream is very active fixing any bug, if reported. About the build speed, yes individually the build speed increase (I can reach pretty much the same build speed by keeping autotools and make it use slibtool that said.) but it makes curl start later in the build chain because it now depends on cmake which is very slow and long to build, so depending on the set of packages one do have to build the speed gain is not necessary true.
(In reply to Baptiste Daroussin from comment #9) See the last section of the desription for the PR I haven't for this specific PR except for bugzilla which sends mail, myself and several others (including multiple committers) have tried before regarding other commits/PRs with low success. As far as patches goes sure, question is why it hasn't occurred for years. I actually did work with upstream to fix issues found. There will always be edge cases regarding deps, if you build a bare bones variant you might get away with it however multiple options including default ones depends on CMake so it's not really an issue in practice?
(In reply to Daniel Engberg from comment #10) It seems to me that this question needs a yes/no reply, but it didn't come. Please be explicit. > do you have his approval and you engage a conversation with him ?
(In reply to Dan Langille from comment #11) Given that there has been no response in this PR (or the previous one regarding curl (PR 283020)) there has been no response from the maintainer in 3 weeks in total. Taking previous attempts into consideration by myself and others it's not uncommon to get no response at all irregardless of separate mails or PRs.
(In reply to Daniel Engberg from comment #12) You have not provided sufficient evidence to warrant maintainer takeover.
(In reply to Dan Langille from comment #13) As I've mentioned before, it's a proposal however the current situation isn't ideal where we currently (for example) have a broken version of curl in tree or for example when we have to wait for weeks to get CVEs to get addressed.
This is not happening, I don't see any good reason to do this. Daniel, you are not in a manager position here, please stop.
(In reply to Mathieu Arnold from comment #15) > Daniel, you are not in a manager position here, please stop. While I also mainly disagree with the proposed change, I think the manager position has nothing to do with that. Anyone has right to propose anything and to advocate their proposed changes. Daniel, please, do not stop contributing even if some of your changes are rejected. At the same time, this statement of yours (and your behavior in past) make me think that you're overly fixed on the "I'm the boss" attitude. I hope to see a day when portmgr become a team acting in an agreement rather than being a group of autocratic actors doing whatever they feel right.
(In reply to Mathieu Arnold from comment #15) Where did I imply that? I simply (and seemingly others given comments in other PRs) want(ed) to improve the way of handling. If the current situation is considered fine then it is what it is.
Created attachment 256002 [details] Patch for curl v4
(In reply to Dan Langille from comment #13) It was never intended as a takeover and I thought I was clear about that in the description. To clarify, I'm not a member of desktop@ but have done work on several ports. (In reply to Gleb Popov from comment #16) Thank you, it was a proposal and nothing else. I do admit that I've been in a sour mood at times where PRs and have been handled better in ways and communication could've been better.
Updated to 8.11.1 in ports 2a3bac310439f8de03b945ae6b596ddf6384d411. Thanks. I received several private emails from committers regarding a pending PR for curl. I apologize for the delay in updating/fixing the port. Due to unexpected changes, I have had very limited time for FreeBSD-related tasks since late November. I have only been able to commit nodejs changes that were prepared in early November. But the situation should be better now. (In reply to Daniel Engberg from comment #2) Thanks. I've added this in the commit.
(In reply to Po-Chuan Hsieh from comment #20) > (In reply to Daniel Engberg from comment #2) > Thanks. I've added this in the commit. The distinfo change of upstream patch is fixed in ports 051f1d77a9579ef4de5f408186fccbcb4fd75775.
(In reply to Joel Bodenmann from comment #5) Possibly beating a dead horse here, but: > I fail to understand how one can argue that an entire group like desktop@ can be under-powered compared to an individual Although I do not want to name names, there are group assignees that do not process a significant proportion of the Bugzilla PRs sent that way. To me, this is an indication that these teams need fresh volunteers. For anyone interested, I will be happy to continue this information off-line, via email.