Bug 283266
| Summary: | ftp/curl: Update to 8.11.1 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Daniel Engberg <diizzy> | ||||||||||
| Component: | Individual Port(s) | Assignee: | Po-Chuan Hsieh <sunpoet> | ||||||||||
| Status: | Closed Not Accepted | ||||||||||||
| Severity: | Affects Only Me | CC: | arrowd, cy, desktop, dvl, jbo, makc, mikael, ml, vishwin | ||||||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(sunpoet) |
||||||||||
| Version: | Latest | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| URL: | https://github.com/curl/curl/releases/tag/curl-8_11_1 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Daniel Engberg
2024-12-11 19:26:14 UTC
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. |