https://github.com/tstack/lnav/releases/tag/v0.12.0
Created attachment 249760 [details] [PATCH] sysutils/lnav: Update 0.11.2 -> 0.12.1
Created attachment 250118 [details] [PATCH] sysutils/lnav: update 0.11.2 -> 0.12.1
Hello, We should keep MASTER_SITES since upstream provides release assets tarballs (tar.gz and tar.bz2) Does upstream droped support for CURL? Is there i«other reason to remove this option? Thanks
Seems like so. Without curl configure fails with this: checking for curl-config... no checking whether libcurl is usable... no configure: error: libcurl required to build ===> Script "configure" failed unexpectedly. Don't understand about tarballs: USE_GITHUB already sets MASTER_SITE automatically, so released tarballs (tstack-lnav-v0.12.1_GH0.tar.gz) are downloaded, just as stated in distinfo. It's recommended in porting guide, used widely in ports tree and works well. What's wrong with it?
https://github.com/tstack/lnav/releases/tag/v0.12.2
Created attachment 250266 [details] [PATCH] sysutils/lnav: update 0.11.2 -> 0.12.2
(In reply to Andrey Korobkov from comment #4) > Seems like so. Without curl configure fails with this: https://github.com/tstack/lnav/tree/v0.12.0#prerequisites > Don't understand about tarballs: USE_GITHUB already sets MASTER_SITE > automatically, so released tarballs (tstack-lnav-v0.12.1_GH0.tar.gz) are > downloaded, just as stated in distinfo. > It's recommended in porting guide, used widely in ports tree and works well. > What's wrong with it? https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github Here is a clear example of a project using auto-generated tarbals and release assets "fixed" tarrballs: https://github.com/jordansissel/xdotool/releases/tag/v3.20211022.1
I'm far from taking side in this conflict between "right" and "wrong" tarballs (especially as I have no way to know it in advance unless somethings really would fail to compile). I just think it's a much more generic issue to be decided not on port-by-port basis and hope it will be fixed at bsd.port.mk level (in USE_GITHUB helper) once for all the affected ports. Still don't understand your words: does it mean all the ports using USE_GITHUB are using "wrong" tarballs and are to be fixed? And USE_GITHUB is deprecated now? Or what? Is there any official statement about it? Any plans to resolve the issue? I am not a bit arguing for whatever side of conflict, just waiting for official guidelines on the matter, what to follow. About prerequisites: I didn't have a goal to make this port perfect from the first patch, so didn't include all possible libraries as dependencies. I may try to add them as well if you like. I just tried to update it with minimal changes to compile and work.
(In reply to Andrey Korobkov from comment #8) > Still don't understand your words: does it mean all the ports using USE_GITHUB > are using "wrong" tarballs and are to be fixed? And USE_GITHUB is deprecated > now? Or what? Is there any official statement about it? Any plans to resolve > the issue? > I am not a bit arguing for whatever side of conflict, just waiting for > official guidelines on the matter, what to follow. Not a question of right and wrong but how github works and advises: https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/ What means that ports should use release assets tarbals **when available** since some upstreams projects don't want to follow it. > About prerequisites: I didn't have a goal to make this port perfect from the > first patch, so didn't include all possible libraries as dependencies. I may > try to add them as well if you like. > I just tried to update it with minimal changes to compile and work. I've sent https://github.com/tstack/lnav/tree/v0.12.0#prerequisites link that confirms that curl is a required dep and not an optional: ... libcurl - The cURL library for downloading files from URLs. Version 7.23.0 or higher is required. ...
I took your point now and agree with it. Just could we at least have a separate USE_GITHUB_ASSETS(?) helper for using their assets API? Or better, update old USE_GITHUB one to first test for the presence of assets tarballs and using them when available and fallback to source code tarballs when not? This may significantly lower burden on contributors and maintainers. I'm really skeptic about manually doing the work which could be scripted. At least we may not to fallback to explicitly writing MASTER_SITES, but have some helper for it. What do you think?
(In reply to Andrey Korobkov from comment #10) MASTER_SITES is already covered in USE_GITHUB related when it points to /archive auto-gen tarbals: Mk/bsd.sites.mk:DEV_WARNING+= "MASTER_SITES contains ${MASTER_SITES:M*/github.com/*/archive/*}, please use USE_GITHUB instead." And when a release asset is available it will be in /release dir and then we should use "classic way" MASTER_SITES=/url/to/release/assets Resuming: - First we use MASTER_SITES - Second we switch to USE_GITHUB, USE_GITLAB, etc, when no release assets available, with the need of defining GH_ACCOUNT and GH_PROJECT Take a look at Mk/bsd.sites.mk to see how it works.
You told me how it works for now. I was asking for changing the way how it works in changed conditions. Or at least some reasons, why it cannot be fixed for us to not to have to use MASTER_SITES manually. Or why it shouldn't even be fixed so.
(In reply to Andrey Korobkov from comment #12) We are working in a pkg build framework and things works like that and there are plenty of docs available to learn how and why it works this way.
I am in no way into asking you to do any work on pkg build framework just to make me happy. I just wondered, why do you speak of that framework as something that can't be changed to make all the devs, you including, happy! The only mentioning of github release assets in the docs (I assume porting guide) is the short message without any details and explanations: https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github > As of 2023-02-21 GitHub have announced that source downloads will be stable for a year. >Please switch to release assets and if not available ask upstream to generate ones. Does it mean that even after more than a year no one have any better plan than upgrading all that thousands of ports by hand? WHY??
(In reply to Andrey Korobkov from comment #14) This discussion is way beyond the porpose of this PR. I suggest ports@FreeBSD.org mailing to share your point of view.
maintainer timeout
Could we proceed with update? I will need a patch that restores MASTER_SITES so commit be authored by you. Shall we? Thanks
Let's ask ask The Elders — The Core Team: whether it's wise or just stubborn to force me and other contributors to do a lot of work by hand rather than by script helpers, especially without any plans to ever have it automated.
(In reply to Andrey Korobkov from comment #18) wow
If there's a policy discussion to be had here it belongs on the ports mailing list.
I asked for answer from all The Elders.
Send mail to the ports list. Do not add core to CC again.
We've been over this before, just use MASTER_SITES and be done with it as stated in Porters Handbook.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e71089444013a5dc959380e66cfb42cdb969a252 commit e71089444013a5dc959380e66cfb42cdb969a252 Author: Andrey Korobkov <alster@vinterdalen.se> AuthorDate: 2024-04-30 07:07:19 +0000 Commit: Nuno Teixeira <eduardo@FreeBSD.org> CommitDate: 2024-04-30 07:07:19 +0000 sysutils/lnav: Update to 0.12.2 - Define LICENSE_FILE - Building without CURL is not an option now in upstream (libcurl required to build) ChangeLog: https://github.com/tstack/lnav/blob/master/NEWS.md PR: 278000 Reported by: Mohamed Akram <mohd.akram@outlook.com> sysutils/lnav/Makefile | 18 ++++++------------ sysutils/lnav/distinfo | 6 +++--- sysutils/lnav/pkg-descr | 2 +- 3 files changed, 10 insertions(+), 16 deletions(-)
Committed keeping MASTER_SITES. Thank you!
Thank you too! :)